[8] oauth_callback は、 OAuth 1.0
においてコールバックの URL を指定する引数です。
oauth_callback 引数[2] oauth_callback 引数は、クライアントが一時credentials要求で鯖に指定します
>>1。
この引数は必須です >>1。
[3] その値は、資源所有者認可の完了時に鯖が資源所有者をリダイレクトして戻す先の絶対URL を表します >>1。
[4] クライアントがコールバックを受信できない時や、コールバックの URL
を他の方法で指定する時には、値を oob としなければなりません >>1。
[7] 資源所有者認可において資源所有者がアクセスを認めたら、
資源所有者は oauth_callback その他の方法で指定されたコールバック
URL にリダイレクトされます >>6。その場合 query
に引数が追加されます。あるいは oob
の場合は、リダイレクトのかわりに検証符号が表示されます >>6。
[89] Vitadock は oauth_callback を使わず、事前に設定した固定の値としています >>88。
[86] Twitter は oauth_callback=oob のことを
PIN-Based OAuth と呼んでいます >>87。
[20] 認可鯖は認可エンドポイントで資源所有者とのやり取りが完了したら、 資源所有者をクライアントのリダイレクトエンドポイントへとリダイレクトします。 >>19
[21] 認可鯖がリダイレクトする URL は、 クライアントの登録の際に指定されたものか、 認可要求を行った際に指定されたものです >>19。
[22] リダイレクトエンドポイントの URL は、
RFC 3986 絶対URIでなければなりません。
application/x-www-form-urlencoded
形式の URL query を含んでも構いません。
素片識別子を含んではなりません。
query に引数を追加するときは、元の query があれば残さなければなりません。
>>19
[23] リダイレクトエンドポイントは、要求の response_type
が code や token の時や、
リダイレクトエンドポイントが開放型ネットワーク上を繊細な credentials
を転送させることとなる時には、 TLS を使うべきです >>19。
クライアントはリダイレクトURLがネットワーク上の資源を表す時は、
TLS を使うべきです >>55, >>75。
クライアントが資源所有者の認証を認可符号によって行う時は、
TLS を使わなければなりません >>55。
アクセストークンを送信する時は、 TLS を使わなければなりません >>54。
[24] 認可鯖は、リダイレクトエンドポイントが TLS を使わない時は、 資源所有者に対して安全でないことを警告するべきです >>19。
[25] 認可鯖は、クライアント型が公開のクライアント >>19, >>61 や、 暗示的承諾型を使うクライアント型が機密のクライアント >>19 については、 クライアントの登録時にリダイレクトエンドポイントを指定させなければなりません >>19。 クライアントの性質上クライアント認証が行えないものに対しても、指定させなければなりません >>53。 またすべてのクライアントに対し、認可エンドポイントの利用に先立ちリダイレクトエンドポイントの登録を求めるべきです >>19, >>61。
[26] 認可鯖は、クライアントが複数のリダイレクトエンドポイントを登録することを認めても構いません >>19。
[28] 認可鯖は、クライアントに完全なリダイレクトURLを指定することを求めるべきです。
そうでなくても、 URL scheme、authority、path を指定することを求めるべきです。
完全なリダイレクトURLを指定させても、クライアントは state
引数により要求ごとのカスタマイズを行えます。そうでない場合は、
クライアントは query の部分に限って動的に変更できます。 >>19
[52] リダイレクトURLは、クライアント認証が機能しない場合の安全性の確保のために補助的に用いられることがあります。
[73] なお、リダイレクトURLの登録とそれによる制限は、credentials が第三者の手にわたることをできるだけ防ぐことを狙ってはいますが、 独自の URL scheme によってネイティブアプリケーションを起動する場合など、 本来のクライアントに伝わるとは保証されない場合もあり、注意が必要です >>72。 認可鯖はリダイレクトURLとして認める URL の種類を制限する必要があるかもしれません。
[74] ある URL scheme を使うスマートフォンアプリが、その URL scheme を使ったリダイレクトURLをクライアント登録時に指定したとします。 そのスマートフォンアプリがインストールされた端末で当該クライアントから OAuth フローを実行すれば、意図通りそのスマートフォンアプリに結果が返されます。
ここで別のスマートフォンアプリがそれと同じ URL scheme を使うと OS に登録すると、以後 OAuth の結果はこちらのスマートフォンアプリに返されることとなります。 このアプリが悪意を持っていなかったとしても、 URL scheme の決め方次第では偶然衝突することはあります。
redirect_uri 引数[29] redirect_uri 引数は、リダイレクトURL
を指定するものです。
[66] この引数の値は、 RFC 3986 URI参照です >>65。
[37] 認可符号やアクセストークンを取得する認可エンドポイントへのアクセスで指定できます >>36, >>40。
[30] 複数のリダイレクトURLが登録されている場合、
リダイレクトURLの一部分のみが登録されている場合、
リダイレクトURLが登録されていない場合には、
クライアントは認可の要求で
redirect_uri 引数を指定しなければなりません >>19。
[31] 認可エンドポイントの要求で redirect_uri 引数が含まれている場合、
認可鯖は、登録されているリダイレクトURLがあればそれと比較しなければなりません >>19, >>46, >>61, >>76。
完全な URL が登録されている場合には、 RFC 3986 単純文字列比較に依らなければなりません >>19, >>46。
[32] 認可の要求でリダイレクトURLが指定されない場合、 非妥当な場合、 一致しない場合には、 認可鯖は資源所有者に誤りを通知するべきです。 非妥当なリダイレクトURLに自動的にリダイレクトしてはなりません。 >>19, >>38
[67] 構文上相対URLを引数に指定することは認められていますが、 それを認可鯖がどう解釈するべきなのかは明記されていません。 比較やリダイレクトの前に解決するべきなのか、 その場合の基底URLが何であるのかは不明確です。 クライアントは相対URLを使うべきではなさそうです。 また認可鯖も相対URLの指定は誤りとみなしてよさそうに思えます。
[39] 認可エンドポイントは資源所有者をリダイレクトエンドポイントにリダイレクトする際に、 クライアントが指定したリダイレクトURLの URL query に引数を追加しなければなりません。
[40] 認可符号が求められている場合、次の引数を追加します >>38。
[33] リダイレクトエンドポイントへのリダイレクトの結果、 資源所有者の利用者エージェントが処理する HTML文書が返されることとなるのが普通です。 >>19 直接 HTML を返すこともできますし、クライアントの他のエンドポイントにリダイレクトしてから HTML を返すこともできます。前者の場合は >>34 の通り注意が必要です。
[35] いずれにせよ、クライアントはクライアントエンドポイントへのアクセスがあれば、 その要求に含まれる認証符号をトークンエンドポイントに送信してアクセストークンを得ることが期待されています。
[44] クライアントから認可鯖のトークンエンドポイントへの認可符号からアクセストークンを取得する要求には、
認可エンドポイントで指定したのと同じ redirect_uri
引数を (あれば) 指定しなければなりません >>43。
[45] 認可鯖は、認可エンドポイントでの認可符号の発行時に
redirect_uri 引数が指定されていたなら、
トークンエンドポイントにおいて同じ値が指定されていることを確認しなければなりません >>43, >>61。
[47] 暗示的承諾型のフローでは、認可エンドポイントからのリダイレクトでは引数は URL query ではなく素片識別子に追加されます。リダイレクトURL は OAuth の処理を直接鯖側で行うのではなく、 OAuth の処理を行う JavaScript アプリケーションを含む HTML文書を返すことが期待されています。
[48] アクセストークンが求められている場合、次の引数を追加します >>46。
[56] クライアントは、資源所有者からリダイレクトURLへの要求があれば、 OAuth として必要な処理 (OAuth 1.0 トークン要求や OAuth 2.0 トークンエンドポイントへの要求の送信) を行いつつ、 資源所有者に次の応答を送る必要があります。 OAuth としては厳密に動作が決められているわけではありませんが、 一般的には資源所有者の Webブラウザーで表示するべき、 OAuth の一連の処理を完了したことを示す HTML文書を送信することが多いようです。
[57] リダイレクトURLへの要求の処理として OAuth 処理をすると同時に HTML文書を応答として返すこともできますが、 一旦再度リダイレクトしてからHTML文書を返すのが普通です。
[34] OAuth 2.0 認可符号フローにおいてリダイレクトエンドポイントが直接 HTML文書を返す場合には、 そこに含まれるスクリプトはリダイレクトURLおよびそこに含まれる credentials にアクセスできます。クライアントは第三者のスクリプト (アクセス解析、ソーシャルプラグイン、広告など) を含めるべきではありません。そのような必要があるなら、 credentials を取り出してから再度他のエンドポイントにリダイレクトし、 credentials にアクセスできないようにするべきです。 そうしない場合には、まずクライアント自身によるスクリプトによって credentials を取り出し除去してから第三者のスクリプトが実行されるようにしなければなりません。 >>19 スクリプトが不正なものに置き換えられることがないようにも、注意が必要です >>82。
[58] 再度リダイレクトしないで HTML文書を返す場合、 >>34 以外であっても第三者のスクリプトがリダイレクトURL や文書中に含まれる credentials にアクセスできてしまいますから、注意が必要です。
[59] 再度リダイレクトしないで HTML文書を返す場合、 そこから第三者の管理する Webサイトへのリンクや画像等があると、 Referrer を通じて credentials が漏れる可能性がある >>70 ので、注意が必要です。
[71] Webブラウザーの履歴により、当該計算機にアクセスできる他の利用者にも URL が漏れる可能性はあります >>70。通常はクライアントが認可符号をすぐにアクセストークンの取得に使うため、 使用済みの認可符号は再利用できなくなりますが、そうでない場合には注意が必要となります。
[63] リダイレクトエンドポイントは、CSRF 対策しなければなりません >>62, >>77, >>83。
state も参照。[11] 鯖は、指定されたコールバックURLが適切なものであるか注意して確認する必要があります。
[10] OAuth 1.0 でも実装によっては、サービス固有の管理画面でコールバックURL を指定したり、認めるコールバックURL のパターンを指定できたりすることがあります。 OAuth 2.0 ではクライアントの登録時にリダイレクトURLを指定するのが原則とされています。
[12] javascript: や data:
のような URL が指定されるのを認めてしまうと、
意図しない起源でスクリプトが実行されるなどセキュリティー上の問題が生じる虞があります。
[13] 一般的でない URL scheme が指定されるのを無条件に認めてしまうと、 第三者への意図しない情報漏洩の注入の機会を生じさせてしまうかもしれず、 鯖は十分注意しなければなりません。
[14] 例えばスマートフォンアプリ向けの URL scheme の指定を認めると、悪意のある第三者が他のスマートフォンアプリの URL scheme を使うスマートフォンアプリを配布し、コールバックURL へのアクセスを“乗っ取る”ことができるかもしれません。
[15] 改行が含まれる URL を指定された場合にそれをそのまま
HTTP Location: ヘッダーに使い、
悪意のあるクライアントが任意の HTTPヘッダーを指定することを認めてしまう、
といったことがないよう鯖は注意が必要です。
[17] OAuth 1.0 クライアントは、コールバックURLへのアクセスが資源所有者の意思に基づき資源所有者認可からリダイレクトされてきたものであり、 CSRF によって意図せず発生させられたものでないことを確認する必要があります >>16。 一時credentials要求を OAuth クライアントに送信させた資源所有者とコールバックURL にアクセスしてきた資源所有者が同一であることは OAuth 仕様としては保証されませんから、 OAuth クライアント側で確認が必要です。
oauth_verifier 引数が追加されてリダイレクトされる
URL となりますが、悪意のある第三者が正当な方法で得た oauth_verifier
引数を付けた URL を用意することが可能ですから、
oauth_verifier が有効な値であるかどうかと CSRF
であるか否かは無関係です。[78] 攻撃者は大量の要求でクライアントに適当な認可符号を与え、認可鯖にアクセスさせることで、
間接的に認可鯖のHTTP接続を枯渇させる DoS攻撃を試みるかもしれません。
認可鯖には攻撃者の情報がほとんど届かず、対策が難しい攻撃です。
クライアントは不適切な認可符号があまりに多い利用者のアクセスを拒むべきかもしれません >>79。
認可鯖にアクセスする前に state 引数による CSRF の検査を行えば攻撃は多少難しくはなりますが、
攻撃者が事前に認可エンドポイントの URL をクライアントから得ておけば
state の値も得られているわけですから、
防止策として完全ではありません >>79。
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.
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
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.
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.
redirect_uris: Where the user should be redirected after authorization (for no redirect, use urn:ietf:wg:oauth:2.0:oob)
oobは「out-of-band configuration」を表します >>1。