こんにちはー。管理人のピヨ猫でーす。
最近仕事でOAuth 2.0を使うことになったんだけどさー、マジ意味わかんねー。助けて。
考え方が分かれば簡単なことだから心配しなくて大丈夫だよ。OAuth 2.0を分かり易く説明するね。
１．OAuth 2.0ってそもそも何？どんな時に必要なの？
OAuth2.0を一言で表すと
OAuth 2.0(オーオース 2.0)はOpenID Foundationが規格策定をしているオープンスタンダードな、APIの認可のためのプロトコルです。
https://openid.net/foundation/
順を追って説明するね。この記事を読み終わった時には上の意味が分かる様になるよ。
APIとは
まず、OAuth 2.0の前にAPIを解説します。
APIは正式にはApplication Programing Interfaceと言います。
APIはあるシステムのデータを他のシステムで使うための仕組みです。
システムに組み込める様に、プログラムから利用できる形で提供されます。
- データをResource、
- データを提供する、あるシステムをResource Server、
- データを使うシステムをClientと呼びます。
分かりやすく身の回りのことに喩えると、
『電話で家族に冷蔵庫に牛乳残ってたっけ？と聞くようなもの』です。
| 名称 | 説明 | 喩え |
|---|---|---|
| API | あるシステムのデータを他のシステムで使う手段 | 電話 |
| Resource | APIで使うデータ | 冷蔵庫に牛乳があるか？という情報(データ) |
| Resource Server | APIで提供するデータを保持しているシステム(あるシステム) | 家族 |
| Client | APIを使いデータを得るシステム | 自分 |
OpenAPIの登場
昔からAPIはありましたが、APIを公開する範囲が自社システムの中など使える範囲が限定的でした。
しかし、最近になりOpenAPIと言う考え方が出てきました。
「APIを広く世界に公開して皆で色々なデータを活用し合おうよ」と言われるようになってきました。
かっこいい言葉を使うと、『オープン・イノベーションの活性化』が推進されるようになったんです。
参考まで、昨今は一番お堅い銀行も、データのオープン化を積極的に推進しています。
https://www.zenginkyo.or.jp/abstract/council/openapi/
APIを利用する側の目的
APIは誰が利用するでしょうか？
APIはプログラムから使う物なので、一般の人はあまり使いません。
APIはAPIが提供するデータを使ったシステムを作り商売がしたい事業者が使うのが一般的です。
たとえばマネーフォワード
という家計簿アプリがあります。このアプリは自分の銀行口座の情報を見ることができますが、アプリの提供会社は銀行ではありません。アプリの提供会社は銀行が提供するAPIを使って貴方の口座情報を取得してアプリに表示しています。
- APIを利用するシステムをClient、
- APIを使っているシステムを使う一般の人をResource Ownerと呼びます。
| 名称 | 説明 | 喩え |
|---|---|---|
| API | あるシステムのデータを他のシステムで使う手段 | 銀行が提供するAPI |
| Resource | APIで使うデータ | 自分の口座情報 |
| Resource Server | APIで提供するデータを保持しているシステム | 銀行 |
| Client | APIを使いデータを得るシステム | 家計簿アプリ(マネーフォワード) |
| Resource Owner | アプリを使う人 | 自分 |
APIを提供する際の注意点
上の例で気になることがありませんか？
APIで口座情報はどこまで見れるのでしょうか？もし、APIで他人の口座情報が見れるようになってたら大変です！！
APIで公開するデータは、APIを間接的に利用しているResource Ownerが閲覧可能な範囲でなければなりません。言い換えると、Resource Ownerの所有データ以外は閲覧・操作出来てはいけません。
ここで、ついにOAuth 2.0の登場です。
OAuth 2.0はAPIで閲覧・操作可能な範囲を、Resource Ownerの所有データに制限するための仕組みです。
２．OAuth 2.0の役割
OAuth 2.0を一言で表すと
前章で述べたことをもう一度言います。
OAuth 2.0はAPIの認可のためのプロトコルです。
はて？認可とは何でしょうか？
認証と認可について
◆認証(Certification)とは何か？
認証は個人を特定することです。
一般的な認証の方法はユーザーIDとパスワードで個人を特定します。
個人を特定することで、適切な範囲でデータを公開することができます。
例えば、LINEやFacebook等を使うときにユーザーIDとパスワードを入れると思います。これが認証(Certification)です。
(※簡単のためパスワード認証を例としています。Google認証などの動きは少し違いますが、ここでは簡単のため説明を割愛します。)
◆認可(Authorization)とは何か？
では、認可とは何でしょうか？
先ほどLINEにログインする際にユーザーIDとパスワードを入れると申しましたが、もし仮にLINEのトークを送る度に、ユーザーIDとパスワードを入れる必要があったらめちゃくちゃ不便ですよね？
そのため、一度、認証したら、その人にLINEを閲覧する権限を与えるのです。これを認可(Authorization)と言います。
認証ほ本人の証明。認可は権限の付与になります。
認証と認可の身近な例
分かりやすく身近な例で認証と認可を例えます。
- 海外旅行に行こうと思います。
- パスポートセンターに、住民票を提出します。(本人の確認＝認証)
- パスポートが発行されます(認可)
これで海外旅行に行く度に住民票を取得する必要がありません。パスポートとは貴方は海外に行けますという権限が与えられたことの証明書です。
これが認可になります。
※ 実際の所、パスポートには顔写真があるので認証機能もあります
OAuth 2.0の役割
OAuth 2.0は認可のやり方を取り決めたものです。
認可も免許証とかパスポートとか社員証とか身近なことでも色々な方法があります。どんな認可手段を使うか決めておかないと皆が混乱します。飛行機に乗るときはパスポートで認可すると決まってますね。同じ様にAPIを使う場合はOAuth 2.0はを使います。
補足ですが、APIではなくLINE等の画面アプリケーションも認可をしています。ただ、画面アプリケーションはそのアプリケーションの中で認可出来ていれば良いので仕組みを公開する必要がありませんでした。しかし、APIは誰かに仕組みを公開するものですので、認可の方法も仕組みを公開する必要がありOAuth 2.0が生まれました。
３．OAuth 2.0の認可の流れ
認可コードとアクセストークン
パスポートの話をもう一度見て見ましょう。
実は簡単のため前回の説明は少し流れを省略していて正確ではありません。
正確には
- 役所に身分証を提出(認証)
- 役所で住民票を発行してもらう(認可コードの発行)
- パスポートセンターに住民票を渡す(認可コードの提出)
- パスポートが発行される(アクセストークンの発行)
- パスポートを見せて飛行機に乗る(アクセストークンを使いAPIを利用する)
となります。
実はパスポートセンターは認証をしていません。
認証(本人確認)をしているのは役所です。何故なら、役所は住民基本台帳があるので本人確認が出来ますが、パスポートセンターには本人確認をする手段がないからです。
- 本人確認をする機関をAuthorization Server、
- パスポートを発行するための書類(住民票)を認可コード(Authorization code)、
- 認可証明書(パスポート)をアクセストークン(Access token)と言います。
OAuth 2.0の流れ
認証と認可の流れを前章で紹介した家計簿アプリで見てみます。
| OAuth 2.0 | 家計簿アプリの動き |
|---|---|
| Resource OwnerがAuthorization Serverで認証を行う。 | 貴方が銀行のインターネットバンキングシステムで認証を行う |
| Authorization Serverが認可コードを発行する。 | 銀行のインターネットバンキングシステムが貴方の認可コードを発行する |
| Resource OwnerがClientに認可コードを提出する。 | 貴方が家計簿アプリに貴方の認可コードを提出する |
| ClientがResource Serverに認可コードを提出する。 | 家計簿アプリが銀行のAPIシステムに貴方の認可コードを提出する |
| Resource ServerがClientにAccess Tokenを発行する。 | 銀行のAPIシステムが家計簿アプリに貴方のアクセストークンを発行する |
| Resource OwnerがClientでResourceの照会をする。 | 貴方が家計簿アプリで貴方の口座情報の照会をする |
| ClientがAPIとアクセストークンを使いResource ServerにResourceの照会をする。 | 家計簿アプリがAPIと貴方のアクセストークンと使い銀行のAPIシステムに貴方の口座情報の照会をする |
| Resource ServerがClientにResourceを返却する。 | 銀行のAPIシステムが家計簿アプリに貴方の口座情報を返却する |
| ClientがResource OwnerにResourceを表示する。 | 家計簿アプリが貴方に口座情報を表示する |
※ 以降、家計簿アプリから口座情報を照会する際に認証は必要ありません。家計簿アプリが貴方のアクセストークンを使い、銀行のAPI管理システムに口座情報の照会を行います。
※ 補足ですが、家計簿アプリが貴方のアクセストークンを使えるのは、家計簿アプリが利用者が貴方であることを特定しているためです。つまり逆に言うと、家計簿アプリにはログイン（認証）が必要です。アクセストークンがあることで認証が必要ないのは銀行のAPIシステムに対してになります。
４．OAuth 2.0の仕様と製品紹介
OAuth 2.0の仕様
OAuth 2.0の仕様はOpenid Foundationジャパンにて公開されているので、そちらを参照ください。
細かくなりすぎるので今回の記事では詳しい解説は割愛します。
OAuth 2.0をサポートした製品
OAuth 2.0はプロトコル（取り決め）であり、実体はありません。
そのため、OAuth 2.0に則ったAPIの認可の仕組みは自分で実装する必要があります。
ただ、それは大変なので、既に大手ベンダーなどがOAuth2.0を実現する製品を提供しているので、OAuth 2.0を使う場合はそれらの製品を使った方が良いです。
【OAuth 2.0をサポートした製品およびOSS（オープンソースソフトウェア）】
| 製品 | 販売元 | 製品リンク |
|---|---|---|
| Classmethod Barista | クラスメソッド | [Classmethod Barista](https://classmethod.jp/news/openid-connect-oauth20-barista/ Classmethod Barista") |
| API Connect | IBM | [IBM](https://www.ibm.com/jp-ja/cloud/api-connect Classmethod Barista") |
| AWS Cognito | Amazon | [AWS Cognito](https://aws.amazon.com/jp/cognito/?sc_channel=PS&sc_campaign=acquisition_JP&sc_publisher=google&sc_medium=cognito_b&sc_content=cognito_e&sc_detail=aws%20cognito&sc_category=cognito&sc_segment=176062790382&sc_matchtype=e&sc_country=JP&sc_brand=brand&ef_id=Cj0KCQjw7sDlBRC9ARIsAD-pDFo7xq2EB4eYr-dJBHJcOFP24hd-aYxVbjTRbxYQEFlW0n4d57sNpqcaAqs-EALw_wcB:G:s AWS Cognito") |
| OSSいろいろ | － | https://developer.ntt.com/ja/blog/27d30623-f460-43af-97c9-10e60433dae4 |
５．OAuth 2.0の注意点
OAuth 2.0は認証の仕組みではない
OAuth 2.0は認証の仕組みではなく、認可の仕組みです。認可コードを発行するための本人確認（認証）の方法はOAuth 2.0で定められてはいません。認証方法は自分で決める必要があります。
認可の流れは１つではない
OAuth 2.0で認可の仕方は取り決められているのですが、Authorization ServerとResource Serverが違う場合/同じ場合や、Clientが提供するサービスがWEBサービスの場合/アプリの場合など、状況によって認可のやり方は少し変わってきます。OAuth 2.0の約束（プロトコル）を守りつつ状況に合わせて認可の仕方は考える必要があります。
参考として Openid Foundationジャパンが、数パターンの認可の流れを照会しているので、参考にしてください。
https://openid-foundation-japan.github.io/rfc6749.ja.html
アクセストークンは絶対に外部に漏らさない
パスポートが盗まれたら不正利用される可能性があるのと同様に、アクセストークンも盗まれたら不正利用される可能性があります。
絶対にアクセストークンは公開してはいけません。APIを利用する事業者はアクセストークンを厳格に管理する必要があります。
また、APIを提供する事業者も、APIを利用する事業者が適切にアクセストークンを管理できる事業者か見極めた上で、APIを提供する必要があります。
↓↓↓ 以下記事で紹介しているGoogle APIはOAuth2.0では無いですが、アクセストークンにてAPIにアクセスします。（正確にはAPIキーというアクセストークンの様なものでAPIにアクセスする）
https://syuuai.hatenablog.com/entry/2018/12/09/000000
Google APIのアクセストークン（APIキー）を万が一外部に漏らすと、自分に変わってGoogle APIを第３者に利用され、大量の請求が来る可能性がありますので、アクセストークンの管理は厳重に行って下さい。
認可コードの有効期限は短くする
認可コードは最終利用者(Resource Owner)に発行します。最終利用者はシステムについて詳しくない方も多いですので、最終利用者が認可コードを絶対に外部流出しない様に管理するのは極めて難しいです。
そのため、認可コードはアクセストークンを発行するための一時的なものとし、認可コードの有効期間は１~１０分程度の短い時間を設定してください。
アクセストークンの有効期間は長めにしても良い
認可コードと違いアクセストークンは事業者が厳格に管理しますので、有効期間を短くする必要はありません。
逆に短すぎると有効期限が過ぎるたびに認証する必要があり、APIの利便性を損なうので３０日などの長い期間を設定するのが良いです。
アクセストークンの有効期間を短めにしてリフレッシュトークンを使うのがもっと安全
今回は細かくなるので詳しく説明しませんが、アクセストークンの有効期間も短めにしておいて、リフレッシュトークンで認証せずにアクセストークンを再発行する方法をとるのが最も安全で利便性も良い方法となります。
６．OAuth 2.0とOpenID Connect
OAuth2.0には認証の取り決めがありません。また、上述した通りアクセストークンは厳格に管理されることが前提で、アクセストークンが流出した場合のケアは万全ではありません。
そのため、OAuth
2.0の認可の仕組みはそのままに、OAuth 2.0の問題点を補完したOpenID Connectというプロトコルが生まれました。
本記事とは別でまた紹介したいと思いますが、参考までリンクを掲載します。
なお、本記事で紹介したOAuth 2.0の認可の仕組みはOpenID Connectでも同じですので、OAuth 2.0の仕組みを抑えることは全く無駄ではありません。
http://www.openid.or.jp/document/
最後に、少し脱線しますが、当ブログで紹介している機械学習のAPIも、アクセストークンにより権限付与されます。アクセストークンが流出すると、第三者に勝手にAPIを使われて、機械学習のAPIを契約している貴方に重量課金される可能性があるので、アクセストークンの管理は厳格にしてください。
それでは、少しでも本記事がお役に立てたら幸いです。
 |
OAuth徹底入門 セキュアな認可システムを適用するための原則と実践 [ Justin Richer ] 価格:4,536円 |
