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