承諾フロー [2] 暗示的承諾implicit grant JavaScript などのスクリプト言語 でブラウザー 上で実装されたクライアント のような、
クライアント型 が公開 であり特定のリダイレクトURL
を使うとわかっているクライアント に最適化された、
単純化されたフローです >>1 , >>8
[11] クライアント は、まず資源所有者 (の利用者エージェント )
を認可エンドポイント にリダイレクト します。
この時クライアント は、クライアント識別子 (client_id 適用範囲 (scope 局所状態 (state リダイレクトURL (redirect_uri >>8
[12] 認可エンドポイント は資源所有者 を認証 し、
クライアント のアクセス要求を承認するか拒絶するかを確認します >>8 アクセストークン を素片識別子 に添えてリダイレクトURL
へとクライアント をリダイレクト します >>8
[13] 資源所有者 の利用者エージェント はリダイレクト に従いクライアント の資源 を要求 しますが、
この時 HTTP要求 には素片識別子 は含まれません。
クライアント は Webページ (通常はスクリプト が埋め込まれた
HTML文書 ) を返します。 Webページ のスクリプト は素片識別子 からアクセストークン その他の引数 を取り出し、
クライアント へと渡します。 >>8
[3] リダイレクトURL で示されていた資源 自体はアクセストークン その他を受け取りません。
素片識別子 に含まれるアクセストークン を処理する JavaScript
アプリケーション を提供するだけです。R 資源所有者 C クライアント S 認可鯖 R -> C OAuth の処理の開始指示C -> R 認可エンドポイント への要求にリダイレクト R -> S 認可エンドポイント への要求 (return_type =token S -> R アクセス要求の承認の確認 R -> S アクセス要求の承認 S -> R リダイレクトURL へのリダイレクト (アクセストークン 付き)R -> C リダイレクトURL への要求 (アクセストークン なし )C -> R リダイレクトURL からの応答#R# アクセストークン の取得R -> C アクセストークン の送信[4] このように、クライアント は (認可符号 を経ずに) アクセストークン を直接得ることができます >>1 , >>8 認可符号 のような中間の credentials を使わないので、
暗示的implicit な承諾型 と呼ばれています >>1 [10] リダイレクト を使っているので、
クライアント は資源所有者 の利用者エージェント (通常は
Webブラウザー ) と対話できるもので、リダイレクト により認可鯖 から要求 を受信できるものである必要があります >>8 [5] 認可鯖 はクライアント認証 を行いません >>1 , >>8 クライアント から認可鯖 への直接のアクセスが無いので、その機会もありません)。
資源所有者 が存在していることと、リダイレクトURL
が登録されていることに依拠しています >>8
[6] アクセストークン はリダイレクトURL に指定されることとなるため、
資源所有者 や、資源所有者 と同じ装置 にある他の応用 に晒されるかもしれません
>>1 , >>8
[7] 暗示的承諾 を使うと認証符号 を使う場合のようなアクセストークン を得るまでの往復を節減でき、
効率的ではありますが、便利さのために若干のセキュリティー を犠牲にしています >>1
[9] 暗示的承諾型 では、更新トークン は発行されません >>8
セキュリティー [18] 暗示的承諾型 を用いている場合、 (悪意のある、または悪意のある者に誘導された)
資源所有者 は他のクライアント から取得したアクセストークン を認可鯖 からの応答 であるかのように見せかけてクライアント に渡すことができてしまいます。
つまり、クライアント を利用する本来の資源所有者 と、クライアント がアクセストークン によって資源鯖 に対して要求を行う操作上の資源所有者 が異なる状態を作れてしまいます。
[19] クライアント 上の本来の資源所有者 のデータが (クライアント の正規の動作により)
資源鯖 に送信されるとアクセストークン の資源所有者 はそのデータを盗むことができてしまいます。
[20] また暗示的承諾型 フローの後に資源鯖 から資源所有者 のアカウント や電子メールアドレス 等を取得して自サービス上のアカウントとする、いわゆるOAuthログイン を使うクライアント があると、他のクライアント において取得したアクセストークン を使ってそのクライアント にも「ログイン 」できてしまいます >>22
[21] 認可符号 フローでは、認可符号 を盗んで他のクライアント に注入したとしても、トークンエンドポイント アクセス時にクライアント認証 が行われればこのような攻撃は防げます (クライアント認証 が行われなければ防げません)。 OAuth 1.0 でも同様です。[25] Google は「TokenInfo validation」と称して、素片識別子 から得たアクセストークン を Google の鯖 に送信してその情報を取得し、
適切なクライアント のアクセストークン であるか確認することを求めています >>24
[14] RFC 6749 - The OAuth 2.0 Authorization Framework (2014-12-15 14:15:35 +09:00 版) http://tools.ietf.org/html/rfc6749#section-10.16 [22] RFC 6819 - OAuth 2.0 Threat Model and Security Considerations (2015-02-10 06:43:00 +09:00 版) http://tools.ietf.org/html/rfc6819#section-4.4.2.6 [15] 単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる « .Nat Zone
(2012-02-03 12:55:56 +09:00 版)
http://www.sakimura.org/2012/02/1487/ [16] OAuthにおける「クライアントサイドに対する認可」なのか「サーバーサイドに対する認可」なのか明確でない問題 - 金利0無利息キャッシング – キャッシングできます - subtech
( (2012-02-19 10:46:54 +09:00 版))
http://subtech.g.hatena.ne.jp/mala/20120214/1329199851 [17] OAuth 2.0でユーザーが認可をする"アプリケーション"とはサービス全体のことではない - r-weblife (2014-09-27 18:54:09 +09:00 版) http://d.hatena.ne.jp/ritou/20120311/1331444771 [24] Using OAuth 2.0 for Client-side Applications - Google Accounts Authentication and Authorization — Google Developers (2014-11-15 06:31:32 +09:00 版) https://developers.google.com/accounts/docs/OAuth2UserAgent#validatetoken [23] Final: OpenID Connect Core 1.0 incorporating errata set 1
(2014-11-09 04:00:29 +09:00 版)
http://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth