[8] [DFN[[CODE(URI)@en[[[oauth_callback]]]]]] は、 [[OAuth 1.0]] において[[コールバック]]の [[URL]] を指定する[[引数]]です。 * 仕様書 [REFS[ - [1] '''[CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版) ''' - [6] [CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版) - [16] [CITE@en[RFC 5849 - The OAuth 1.0 Protocol]] ([TIME[2014-12-28 14:19:21 +09:00]] 版) - [19] '''[CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) ''' - [36] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [38] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [43] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [46] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [53] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [54] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [55] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [61] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [62] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [64] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) - [65] [CITE@en[RFC 6749 - The OAuth 2.0 Authorization Framework]] ([TIME[2014-12-15 14:15:35 +09:00]] 版) ]REFS] * OAuth 1.0 [CODE(URI)@en[oauth_callback]] 引数 [2] [CODE(URI)@en[[[oauth_callback]]]] [[引数]]は、[[クライアント]]が[[一時credentials要求]]で[[鯖]]に指定します [SRC[>>1]]。 この[[引数]]は[['''必須''']]です [SRC[>>1]]。 [3] その値は、[[資源所有者認可]]の完了時に[[鯖]]が[[資源所有者]]を[[リダイレクト]]して戻す先の[[絶対URL]] を表します [SRC[>>1]]。 [4] [[クライアント]]が[[コールバック]]を受信できない時や、[[コールバック]]の [[URL]] を他の方法で指定する時には、値を [CODE(URI)[[[oob]]]] としなければ[['''なりません''']] [SRC[>>1]]。 ;; [5] [CODE[oob]] は「out-of-band configuration」を表します [SRC[>>1]]。 [7] [[資源所有者認可]]において[[資源所有者]]がアクセスを認めたら、 [[資源所有者]]は [CODE(URI)@en[[[oauth_callback]]]] その他の方法で指定された[[コールバック]] [[URL]] に[[リダイレクト]]されます [SRC[>>6]]。その場合 [[query]] に[[引数]]が追加されます。あるいは [CODE[[[oob]]]] の場合は、[[リダイレクト]]のかわりに[[検証符号]]が表示されます [SRC[>>6]]。 ;; [[資源所有者認可]]を参照。 ;; [9] [CODE(URI)@en[[[oauth_callback]]]] は[[必須]]ですが、[[鯖]]はその他の方法で[[コールバック]]先を決定しても良いようです。 [89] [[Vitadock]] は [CODE(HTTP)@en[[[oauth_callback]]]] を使わず、事前に設定した固定の値としています [SRC[>>88]]。 [86] [[Twitter]] は [CODE(URI)@en[[[oauth_callback]]=[[oob]]]] のことを [DFN[[[PIN-Based OAuth]]]] と呼んでいます [SRC[>>87]]。 [REFS[ - [88] [CITE@en[Definitions · Medisana/vitadock-api Wiki]] ([TIME[2015-03-13 09:37:46 +09:00]] 版) - [87] [CITE[PIN-based authorization | Twitter Developers]] ([TIME[2015-03-05 11:28:57 +09:00]] 版) ]REFS] * OAuth 2.0 コールバックエンドポイント [20] [[認可鯖]]は[[認可エンドポイント]]で[[資源所有者]]とのやり取りが完了したら、 [[資源所有者]]を[[クライアント]]の[DFN[[RUBYB[[[リダイレクトエンドポイント]]]@en[redirection endpoint]]]]へと[[リダイレクト]]します。 [SRC[>>19]] ;; [[認可エンドポイント]]も参照。 ** コールバック URL [21] [[認可鯖]]が[[リダイレクト]]する [[URL]] は、 [[クライアントの登録]]の際に指定されたものか、 [[認可]][[要求]]を行った際に指定されたものです [SRC[>>19]]。 [22] [[リダイレクトエンドポイント]]の [[URL]] は、 [[RFC 3986]] [[絶対URI]]でなければ[['''なりません''']]。 [CODE(MIME)@en[[[application/x-www-form-urlencoded]]]] 形式の [[URL query]] を含んでも構いません。 [[素片識別子]]を含んでは[['''なりません''']]。 [[query]] に[[引数]]を追加するときは、元の [[query]] があれば残さなければ[['''なりません''']]。 [SRC[>>19]] [23] [[リダイレクトエンドポイント]]は、[[要求]]の [CODE(URI)@en[[[response_type]]]] が [CODE(URI)@en[[[code]]]] や [CODE(URI)@en[[[token]]]] の時や、 [[リダイレクトエンドポイント]]が[[開放型ネットワーク]]上を繊細な [[credentials]] を転送させることとなる時には、 [[TLS]] を使う[['''べきです''']] [SRC[>>19]]。 [[クライアント]]は[[リダイレクトURL]]が[[ネットワーク]]上の[[資源]]を表す時は、 [[TLS]] を使う[['''べき''']]です [SRC[>>55, >>75]]。 [[クライアント]]が[[資源所有者]]の[[認証]]を[[認可符号]]によって行う時は、 [[TLS]] を使わなければ[['''なりません''']] [SRC[>>55]]。 [[アクセストークン]]を送信する時は、 [[TLS]] を使わなければなりません [SRC[>>54]]。 [REFS[ - [75] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] [24] [[認可鯖]]は、[[リダイレクトエンドポイント]]が [[TLS]] を使わない時は、 [[資源所有者]]に対して安全でないことを警告する[['''べきです''']] [SRC[>>19]]。 ** リダイレクト URL の登録 [25] [[認可鯖]]は、[[クライアント型]]が[[公開]]の[[クライアント]] [SRC[>>19, >>61]] や、 [[暗示的承諾型]]を使う[[クライアント型]]が[[機密]]の[[クライアント]] [SRC[>>19]] については、 [[クライアントの登録]]時に[[リダイレクトエンドポイント]]を指定させなければ[['''なりません''']] [SRC[>>19]]。 クライアントの性質上[[クライアント認証]]が行えないものに対しても、指定させなければ[['''なりません''']] [SRC[>>53]]。 またすべての[[クライアント]]に対し、[[認可エンドポイント]]の利用に先立ち[[リダイレクトエンドポイント]]の登録を求める[['''べきです''']] [SRC[>>19, >>61]]。 [26] [[認可鯖]]は、[[クライアント]]が複数の[[リダイレクトエンドポイント]]を登録することを認めても構いません [SRC[>>19]]。 [28] [[認可鯖]]は、[[クライアント]]に完全な[[リダイレクトURL]]を指定することを求める[['''べきです''']]。 そうでなくても、 [[URL scheme]]、[[authority]]、[[path]] を指定することを求める[['''べきです''']]。 完全な[[リダイレクトURL]]を指定させても、[[クライアント]]は [CODE(URI)@en[[[state]]]] [[引数]]により[[要求]]ごとのカスタマイズを行えます。そうでない場合は、 [[クライアント]]は [[query]] の部分に限って動的に変更できます。 [SRC[>>19]] ;; [27] [[リダイレクトエンドポイント]]の登録を求めないと、 [[認可エンドポイント]]が[RUBY[[[開放型リダイレクト器]]][オープンリダイレクター]]として悪用されるおそれがあります [SRC[>>19, >>64]]。 [[認可符号]]などが第三者にわたるため危険です [SRC[>>68, >>69]]。そうでなくても[[フィッシング]]などに悪用されることがあります。 [REFS[ - [68] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) - [69] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] [52] [[リダイレクトURL]]は、[[クライアント認証]]が機能しない場合の安全性の確保のために補助的に用いられることがあります。 ;; [[クライアント認証]]参照。 [73] なお、[[リダイレクトURL]]の登録とそれによる制限は、[[credentials]] が第三者の手にわたることをできるだけ防ぐことを狙ってはいますが、 独自の [[URL scheme]] によって[[ネイティブアプリケーション]]を起動する場合など、 本来の[[クライアント]]に伝わるとは保証されない場合もあり、注意が必要です [SRC[>>72]]。 [[認可鯖]]は[[リダイレクトURL]]として認める [[URL]] の種類を制限する必要があるかもしれません。 [EG[ [74] ある [[URL scheme]] を使う[[スマートフォンアプリ]]が、その [[URL scheme]] を使った[[リダイレクトURL]]を[[クライアント登録]]時に指定したとします。 その[[スマートフォンアプリ]]がインストールされた端末で当該[[クライアント]]から [[OAuth]] フローを実行すれば、意図通りその[[スマートフォンアプリ]]に結果が返されます。 ここで別の[[スマートフォンアプリ]]がそれと同じ [[URL scheme]] を使うと [[OS]] に登録すると、以後 [[OAuth]] の結果はこちらの[[スマートフォンアプリ]]に返されることとなります。 このアプリが悪意を持っていなかったとしても、 [[URL scheme]] の決め方次第では偶然衝突することはあります。 ]EG] [REFS[ - [72] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) - [84] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] ** [CODE(URI)@en[redirect_uri]] 引数 [29] [CODE(URI)@en[[[redirect_uri]]]] [[引数]]は、[[リダイレクトURL]] を指定するものです。 [66] この[[引数]]の値は、 [[RFC 3986]] [[URI参照]]です [SRC[>>65]]。 [37] [[認可符号]]や[[アクセストークン]]を取得する[[認可エンドポイント]]へのアクセスで指定できます [SRC[>>36, >>40]]。 [30] 複数の[[リダイレクトURL]]が登録されている場合、 [[リダイレクトURL]]の一部分のみが登録されている場合、 [[リダイレクトURL]]が登録されていない場合には、 [[クライアント]]は[[認可]]の要求で [CODE(URI)@en[[[redirect_uri]]]] [[引数]]を指定しなければ[['''なりません''']] [SRC[>>19]]。 [31] [[認可エンドポイント]]の要求で [CODE(URI)@en[[[redirect_uri]]]] [[引数]]が含まれている場合、 [[認可鯖]]は、登録されている[[リダイレクトURL]]があればそれと[[比較]]しなければ[['''なりません''']] [SRC[>>19, >>46, >>61, >>76]]。 完全な [[URL]] が登録されている場合には、 [[RFC 3986]] [[単純文字列比較]]に依らなければ[['''なりません''']] [SRC[>>19, >>46]]。 [32] [[認可]]の要求で[[リダイレクトURL]]が指定されない場合、 非妥当な場合、 一致しない場合には、 [[認可鯖]]は[[資源所有者]]に[[誤り]]を通知する[['''べき''']]です。 非妥当な[[リダイレクトURL]]に自動的に[[リダイレクト]]しては[['''なりません''']]。 [SRC[>>19, >>38]] [REFS[ - [76] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] [67] 構文上[[相対URL]]を[[引数]]に指定することは認められていますが、 それを[[認可鯖]]がどう解釈するべきなのかは明記されていません。 [[比較]]や[[リダイレクト]]の前に[[解決]]するべきなのか、 その場合の[[基底URL]]が何であるのかは不明確です。 [[クライアント]]は[[相対URL]]を使うべきではなさそうです。 また[[認可鯖]]も[[相対URL]]の指定は[[誤り]]とみなしてよさそうに思えます。 ** 認可符号フロー *** リダイレクトURLの引数 [39] [[認可エンドポイント]]は[[資源所有者]]を[[リダイレクトエンドポイント]]に[[リダイレクト]]する際に、 [[クライアント]]が指定した[[リダイレクトURL]]の [[URL query]] に[[引数]]を追加しなければなりません。 [40] [[認可符号]]が求められている場合、次の[[引数]]を追加します [SRC[>>38]]。 [FIG(list members)[ :[CODE(URI)@en[[[code]]]]:[[認可符号]]。 :[CODE(URI)@en[[[state]]]]:[[局所状態]]。[[CSRF]] 対策に使います。 ]FIG] ;; [[認可エンドポイント]]を参照。 [41] [[クライアント]]は、認識できない[[引数]]を無視しなければ[['''なりません''']] [SRC[>>38]]。 [42] [[クライアント]]は[[認可符号]]の長さについて仮定するべきではありません [SRC[>>38]]。 *** リダイレクトエンドポイントの処理 [33] [[リダイレクトエンドポイント]]への[[リダイレクト]]の結果、 [[資源所有者]]の[[利用者エージェント]]が処理する [[HTML文書]]が返されることとなるのが普通です。 [SRC[>>19]] 直接 [[HTML]] を返すこともできますし、[[クライアント]]の他の[[エンドポイント]]に[[リダイレクト]]してから [[HTML]] を返すこともできます。前者の場合は >>34 の通り注意が必要です。 [35] いずれにせよ、[[クライアント]]は[[クライアントエンドポイント]]へのアクセスがあれば、 その[[要求]]に含まれる[[認証符号]]を[[トークンエンドポイント]]に送信して[[アクセストークン]]を得ることが期待されています。 [44] [[クライアント]]から[[認可鯖]]の[[トークンエンドポイント]]への[[認可符号]]から[[アクセストークン]]を取得する[[要求]]には、 [[認可エンドポイント]]で指定したのと同じ [CODE(URI)@en[[[redirect_uri]]]] [[引数]]を (あれば) 指定しなければ[['''なりません''']] [SRC[>>43]]。 [45] [[認可鯖]]は、[[認可エンドポイント]]での[[認可符号]]の発行時に [CODE(URI)@en[[[redirect_uri]]]] [[引数]]が指定されていたなら、 [[トークンエンドポイント]]において同じ値が指定されていることを確認しなければ[['''なりません''']] [SRC[>>43, >>61]]。 ** 暗示的承諾フローでのリダイレクト URL [47] [[暗示的承諾型]]のフローでは、[[認可エンドポイント]]からの[[リダイレクト]]では[[引数]]は [[URL query]] ではなく[[素片識別子]]に追加されます。[[リダイレクトURL]] は [[OAuth]] の処理を直接[[鯖]]側で行うのではなく、 [[OAuth]] の処理を行う [[JavaScript]] [[アプリケーション]]を含む [[HTML文書]]を返すことが期待されています。 ;; [[認可エンドポイント]]を参照。 [48] [[アクセストークン]]が求められている場合、次の[[引数]]を追加します [SRC[>>46]]。 [FIG(list members)[ :[CODE(URI)@en[[[access_token]]]]:[[アクセストークン]]。 :[CODE(URI)@en[[[token_type]]]]:[[トークン]]の種別。 :[CODE(URI)@en[[[expires_in]]]]:[[アクセストークン]]の[[寿命]]。 :[CODE(URI)@en[[[scope]]]]:[[アクセストークン]]の[[適用範囲]]。 :[CODE(URI)@en[[[state]]]]:[[局所状態]]。[[CSRF]] 対策に使います。 ]FIG] ;; [49] [[HTTP]] では[[素片識別子]]は[[要求URL]]に含まれませんから、 これらの[[引数]]には [[JavaScript]] からはアクセスできますが、[[鯖]]は直接アクセスできません。 [50] [[クライアント]]は、認識できない[[引数]]を無視しなければ[['''なりません''']] [SRC[>>46]]。 [51] [[クライアント]]は[[アクセストークン]]の長さについて仮定するべきではありません [SRC[>>38]]。 * リダイレクトエンドポイントの応答 [56] [[クライアント]]は、[[資源所有者]]から[[リダイレクトURL]]への[[要求]]があれば、 [[OAuth]] として必要な処理 ([[OAuth 1.0]] [[トークン要求]]や [[OAuth 2.0]] [[トークンエンドポイント]]への要求の送信) を行いつつ、 [[資源所有者]]に次の[[応答]]を送る必要があります。 [[OAuth]] としては厳密に動作が決められているわけではありませんが、 一般的には[[資源所有者]]の [[Webブラウザー]]で表示するべき、 [[OAuth]] の一連の処理を完了したことを示す [[HTML文書]]を送信することが多いようです。 [57] [[リダイレクトURL]]への[[要求]]の処理として [[OAuth]] 処理をすると同時に [[HTML文書]]を[[応答]]として返すこともできますが、 一旦再度[[リダイレクト]]してから[[HTML文書]]を返すのが普通です。 ;; ただし[[暗示的承諾型]]フローでは [[OAuth]] 処理をするのは[[クライアント]]側の[[鯖]]ではなく、 返された [[HTML文書]]に含まれる [[JavaScript]] ですから、[[リダイレクト]]してはいけません。 [[リダイレクト]]すると[[素片識別子]]に含まれる情報にアクセスできなくなってしまいます。 [34] [[OAuth 2.0]] [[認可符号]]フローにおいて[[リダイレクトエンドポイント]]が直接 [[HTML文書]]を返す場合には、 そこに含まれる[[スクリプト]]は[[リダイレクトURL]]およびそこに含まれる [[credentials]] にアクセスできます。[[クライアント]]は[[第三者]]の[[スクリプト]] ([[アクセス解析]]、[[ソーシャルプラグイン]]、[[広告]]など) を含める[['''べきではありません''']]。そのような必要があるなら、 [[credentials]] を取り出してから再度他の[[エンドポイント]]に[[リダイレクト]]し、 [[credentials]] にアクセスできないようにする[['''べきです''']]。 そうしない場合には、まず[[クライアント]]自身による[[スクリプト]]によって [[credentials]] を取り出し除去してから[[第三者]]の[[スクリプト]]が実行されるようにしなければ[['''なりません''']]。 [SRC[>>19]] [[スクリプト]]が不正なものに置き換えられることがないようにも、注意が必要です [SRC[>>82]]。 [58] 再度[[リダイレクト]]しないで [[HTML文書]]を返す場合、 >>34 以外であっても第三者の[[スクリプト]]が[[リダイレクトURL]] や[[文書]]中に含まれる [[credentials]] にアクセスできてしまいますから、注意が必要です。 [59] 再度[[リダイレクト]]しないで [[HTML文書]]を返す場合、 そこから第三者の管理する [[Webサイト]]への[[リンク]]や[[画像]]等があると、 [[Referrer]] を通じて [[credentials]] が漏れる可能性がある [SRC[>>70]] ので、注意が必要です。 [REFS[ - [70] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) - [82] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] ;; [60] [[HTTPS]] のページでも、 [[Referrer]] は送信されます。 [71] [[Webブラウザー]]の履歴により、当該[[計算機]]にアクセスできる他の[[利用者]]にも [[URL]] が漏れる可能性はあります [SRC[>>70]]。通常は[[クライアント]]が[[認可符号]]をすぐに[[アクセストークン]]の取得に使うため、 使用済みの[[認可符号]]は再利用できなくなりますが、そうでない場合には注意が必要となります。 [63] [[リダイレクトエンドポイント]]は、[[CSRF]] 対策しなければ[['''なりません''']] [SRC[>>62, >>77, >>83]]。 ;; [CODE(URI)@en[[[state]]]] も参照。 [REFS[ - [77] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) - [83] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] * セキュリティー [11] [[鯖]]は、指定された[[コールバックURL]]が適切なものであるか注意して確認する必要があります。 [10] [[OAuth 1.0]] でも実装によっては、サービス固有の管理画面で[[コールバックURL]] を指定したり、認める[[コールバックURL]] のパターンを指定できたりすることがあります。 [[OAuth 2.0]] では[[クライアント]]の登録時に[[リダイレクトURL]]を指定するのが原則とされています。 [12] [CODE(URI)@en[[[javascript:]]]] や [CODE(URI)@en[[[data:]]]] のような [[URL]] が指定されるのを認めてしまうと、 意図しない[[起源]]で[[スクリプト]]が実行されるなど[[セキュリティー]]上の問題が生じる虞があります。 [13] 一般的でない [[URL scheme]] が指定されるのを無条件に認めてしまうと、 第三者への意図しない情報漏洩の注入の機会を生じさせてしまうかもしれず、 [[鯖]]は十分注意しなければなりません。 [EG[ [14] 例えば[[スマートフォンアプリ]]向けの [[URL scheme]] の指定を認めると、悪意のある第三者が他の[[スマートフォンアプリ]]の [[URL scheme]] を使う[[スマートフォンアプリ]]を配布し、[[コールバックURL]] へのアクセスを“乗っ取る”ことができるかもしれません。 ]EG] [15] [[改行]]が含まれる [[URL]] を指定された場合にそれをそのまま [[HTTP]] [CODE(HTTP)@en[[[Location:]]]] [[ヘッダー]]に使い、 悪意のある[[クライアント]]が任意の [[HTTPヘッダー]]を指定することを認めてしまう、 といったことがないよう[[鯖]]は注意が必要です。 [17] [[OAuth 1.0]] [[クライアント]]は、[[コールバックURL]]へのアクセスが[[資源所有者]]の意思に基づき[[資源所有者認可]]から[[リダイレクト]]されてきたものであり、 [[CSRF]] によって意図せず発生させられたものでないことを確認する必要があります [SRC[>>16]]。 [[一時credentials要求]]を [[OAuth]] [[クライアント]]に送信させた[[資源所有者]]と[[コールバックURL]] にアクセスしてきた[[資源所有者]]が同一であることは [[OAuth]] 仕様としては保証されませんから、 [[OAuth]] [[クライアント]]側で確認が必要です。 ;; [18] [[コールバックURL]]には [CODE(URI)@en[[[oauth_verifier]]]] [[引数]]が追加されて[[リダイレクト]]される [[URL]] となりますが、悪意のある第三者が正当な方法で得た [CODE(URI)@en[[[oauth_verifier]]]] [[引数]]を付けた [[URL]] を用意することが可能ですから、 [CODE(URI)@en[[[oauth_verifier]]]] が有効な値であるかどうかと [[CSRF]] であるか否かは無関係です。 [78] 攻撃者は大量の[[要求]]で[[クライアント]]に適当な[[認可符号]]を与え、[[認可鯖]]にアクセスさせることで、 間接的に[[認可鯖]]の[[HTTP接続]]を枯渇させる [[DoS攻撃]]を試みるかもしれません。 [[認可鯖]]には攻撃者の情報がほとんど届かず、対策が難しい攻撃です。 [[クライアント]]は不適切な[[認可符号]]があまりに多い[[利用者]]のアクセスを拒むべきかもしれません [SRC[>>79]]。 [[認可鯖]]にアクセスする前に [CODE(URI)@en[[[state]]]] [[引数]]による [[CSRF]] の検査を行えば攻撃は多少難しくはなりますが、 攻撃者が事前に[[認可エンドポイント]]の [[URL]] を[[クライアント]]から得ておけば [CODE(URI)@en[[[state]]]] の値も得られているわけですから、 防止策として完全ではありません [SRC[>>79]]。 [REFS[ - [79] [CITE@en[RFC 6819 - OAuth 2.0 Threat Model and Security Considerations]] ([TIME[2015-02-10 06:43:00 +09:00]] 版) ]REFS] ;; [80] 普通に使っていれば[[認可符号]]が不正になることなどないはずですから ([[認可符号]]が発行されてから時間が経っていてタイムアウトしていた場合、 履歴から[[戻る]]などで使用済みの[[認可符号]]付き[[リダイレクトURL]] に戻ってきた時や[[資源所有者]]と[[クライアント]]の間のネットワークエラーなどで[[認可符号]]付き[[リダイレクトURL]]に再度アクセスがあった時、 [[クライアント]]と[[認可鯖]]の間のネットワークエラーなどで[[認可符号]]が使用済みになった場合や[[認可鯖]]に接続できなった場合くらいでしょうか。)、 一定時間内に数回、同じ[[利用者エージェント]]からの[[認可符号]]でエラーになったことを[[クライアント]]内で記憶しておけば良さそうです。 ;; [81] [CODE[[[oauth_callback]]=[[oob]]]] の時は[[利用者]]の入力ミスを考慮する必要があります。 [FIG(quote)[ [FIGCAPTION[ [85] [CITE@ja[Using OAuth 2.0 for Installed Applications - Google Accounts Authentication and Authorization — Google Developers]] ([TIME[2014-12-05 11:52:26 +09:00]] 版) ]FIGCAPTION] > http://localhost > This value signals to the Google Authorization Server that the authorization code should be returned as a query string parameter to the web server on the client. You may specify a port number without changing the Google Developers Console configuration. To receive the authorization code using this URL, your application must be listening on the local web server. This is possible on many, but not all, platforms. If your platform supports it, this is the recommended mechanism for obtaining the authorization code. > Note: In some cases, although it is possible to listen, other software (such as a Windows firewall) prevents delivery of the message without significant client configuration. > urn:ietf:wg:oauth:2.0:oob > This value signals to the Google Authorization Server that the authorization code should be returned in the title bar of the browser, with the page text prompting the user to copy the code and paste it in the application (as shown in the screenshot above). This is useful when the client (such as a Windows application) cannot listen on an HTTP port without significant client configuration. > When you use this value, your application can then detect that the page has loaded, and can read the title of the HTML page to obtain the authorization code. It is then up to your application to close the browser window if you want to ensure that the user never sees the page that contains the authorization code. The mechanism for doing this varies from platform to platform. > If your platform doesn't allow you to detect that the page has loaded or read the title of the page, you can have the user paste the code back to your application, as prompted by the page text. > urn:ietf:wg:oauth:2.0:oob:auto > This is identical to urn:ietf:wg:oauth:2.0:oob, but the text in the confirmation page won't instruct the user to copy the authorization code, but instead will simply ask the user to close the window. > This is useful when your application reads the title of the HTML page (by checking window titles on the desktop, for example) to obtain the authorization code, but can't close the page on its own. ]FIG] [FIG(quote)[ [FIGCAPTION[ [90] [CITE[Authorize | Content API]] ([TIME[2015-08-29 17:30:00 +09:00]] 版) ]FIGCAPTION] > redirect_uri > required > An HTTPS URI or custom URL scheme where the response will be redirected. Must be https and also be registered within the Box app management console. In development, local http hosts are also accepted as outlined in the tutorial. > Type: uri ]FIG] [FIG(quote)[ [FIGCAPTION[ [91] [CITE@ja[Manually Build a Login Flow - Facebook Login]] ([TIME[2016-03-03 14:15:58 +09:00]] 版) ]FIGCAPTION] > redirect_uri. The URL that you want to redirect the person logging in back to. This URL will capture the response from the Login Dialog. If you are using this in a webview within a desktop app, this must be set to https://www.facebook.com/connect/login_success.html. ]FIG] [FIG(quote)[ [FIGCAPTION[ [92] [CITE@en[Using OAuth 2.0 — Fitbit Web API Docs]] ([TIME[2016-10-05 06:00:11 +09:00]]) ]FIGCAPTION] > The redirect URI may use any protocol. If HTTP is used, Fitbit strongly recommends (and may require in the future) the use of a Transport Layer Security (TLS) protocol. > Note: When using the Authorization Code Grant Flow, Fitbit will also append #_=_ at the end of your redirect URI upon success or failure of the authorization. ]FIG] [FIG(quote)[ [FIGCAPTION[ [93] [CITE@en[documentation/API.md at master · tootsuite/documentation]] ([TIME[2017-04-14 00:47:15 +09:00]]) ]FIGCAPTION] > redirect_uris: Where the user should be redirected after authorization (for no redirect, use urn:ietf:wg:oauth:2.0:oob) ]FIG]