client redirect URI

コールバックURL (OAuth)

[8] oauth_callback は、 OAuth 1.0 においてコールバックURL を指定する引数です。

仕様書

OAuth 1.0 oauth_callback 引数

[2] oauth_callback 引数は、クライアント一時credentials要求に指定します >>1。 この引数必須です >>1

[3] その値は、資源所有者認可の完了時に資源所有者リダイレクトして戻す先の絶対URL を表します >>1

[4] クライアントコールバックを受信できない時や、コールバックURL を他の方法で指定する時には、値を oob としなければなりません >>1

[5] oob は「out-of-band configuration」を表します >>1

[7] 資源所有者認可において資源所有者がアクセスを認めたら、 資源所有者oauth_callback その他の方法で指定されたコールバック URLリダイレクトされます >>6。その場合 query引数が追加されます。あるいは oob の場合は、リダイレクトのかわりに検証符号が表示されます >>6

[9] oauth_callback必須ですが、はその他の方法でコールバック先を決定しても良いようです。

[89] Vitadockoauth_callback を使わず、事前に設定した固定の値としています >>88

[86] Twitteroauth_callback=oob のことを PIN-Based OAuth と呼んでいます >>87

OAuth 2.0 コールバックエンドポイント

[20] 認可鯖認可エンドポイント資源所有者とのやり取りが完了したら、 資源所有者クライアントリダイレクトエンドポイント (redirection endpoint) へとリダイレクトします。 >>19

コールバック URL

[21] 認可鯖リダイレクトする URL は、 クライアントの登録の際に指定されたものか、 認可要求を行った際に指定されたものです >>19

[22] リダイレクトエンドポイントURL は、 RFC 3986 絶対URIでなければなりませんapplication/x-www-form-urlencoded 形式の URL query を含んでも構いません。 素片識別子を含んではなりませんquery引数を追加するときは、元の query があれば残さなければなりません>>19

[23] リダイレクトエンドポイントは、要求response_typecodetoken の時や、 リダイレクトエンドポイント開放型ネットワーク上を繊細な credentials を転送させることとなる時には、 TLS を使うべきです >>19クライアントリダイレクトURLネットワーク上の資源を表す時は、 TLS を使うべきです >>55, >>75クライアント資源所有者認証認可符号によって行う時は、 TLS を使わなければなりません >>55アクセストークンを送信する時は、 TLS を使わなければなりません >>54

[24] 認可鯖は、リダイレクトエンドポイントTLS を使わない時は、 資源所有者に対して安全でないことを警告するべきです >>19

リダイレクト URL の登録

[25] 認可鯖は、クライアント型公開クライアント >>19, >>61 や、 暗示的承諾型を使うクライアント型機密クライアント >>19 については、 クライアントの登録時にリダイレクトエンドポイントを指定させなければなりません >>19。 クライアントの性質上クライアント認証が行えないものに対しても、指定させなければなりません >>53。 またすべてのクライアントに対し、認可エンドポイントの利用に先立ちリダイレクトエンドポイントの登録を求めるべきです >>19, >>61

[26] 認可鯖は、クライアントが複数のリダイレクトエンドポイントを登録することを認めても構いません >>19

[28] 認可鯖は、クライアントに完全なリダイレクトURLを指定することを求めるべきです。 そうでなくても、 URL schemeauthoritypath を指定することを求めるべきです。 完全なリダイレクト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の指定は誤りとみなしてよさそうに思えます。

認可符号フロー

リダイレクトURLの引数

[39] 認可エンドポイント資源所有者リダイレクトエンドポイントリダイレクトする際に、 クライアントが指定したリダイレクトURLURL query引数を追加しなければなりません。

[40] 認可符号が求められている場合、次の引数を追加します >>38

code
認可符号
state
局所状態CSRF 対策に使います。

[41] クライアントは、認識できない引数を無視しなければなりません >>38

[42] クライアント認可符号の長さについて仮定するべきではありません >>38

リダイレクトエンドポイントの処理

[33] リダイレクトエンドポイントへのリダイレクトの結果、 資源所有者利用者エージェントが処理する HTML文書が返されることとなるのが普通です。 >>19 直接 HTML を返すこともできますし、クライアントの他のエンドポイントリダイレクトしてから HTML を返すこともできます。前者の場合は >>34 の通り注意が必要です。

[35] いずれにせよ、クライアントクライアントエンドポイントへのアクセスがあれば、 その要求に含まれる認証符号トークンエンドポイントに送信してアクセストークンを得ることが期待されています。

[44] クライアントから認可鯖トークンエンドポイントへの認可符号からアクセストークンを取得する要求には、 認可エンドポイントで指定したのと同じ redirect_uri 引数を (あれば) 指定しなければなりません >>43

[45] 認可鯖は、認可エンドポイントでの認可符号の発行時に redirect_uri 引数が指定されていたなら、 トークンエンドポイントにおいて同じ値が指定されていることを確認しなければなりません >>43, >>61

暗示的承諾フローでのリダイレクト URL

[47] 暗示的承諾型のフローでは、認可エンドポイントからのリダイレクトでは引数URL query ではなく素片識別子に追加されます。リダイレクトURLOAuth の処理を直接側で行うのではなく、 OAuth の処理を行う JavaScript アプリケーションを含む HTML文書を返すことが期待されています。

[48] アクセストークンが求められている場合、次の引数を追加します >>46

access_token
アクセストークン
token_type
トークンの種別。
expires_in
アクセストークン寿命
scope
アクセストークン適用範囲
state
局所状態CSRF 対策に使います。

[49] HTTP では素片識別子要求URLに含まれませんから、 これらの引数には JavaScript からはアクセスできますが、は直接アクセスできません。

[50] クライアントは、認識できない引数を無視しなければなりません >>46

[51] クライアントアクセストークンの長さについて仮定するべきではありません >>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 を取り出し除去してから第三者スクリプトが実行されるようにしなければなりません>>19 スクリプトが不正なものに置き換えられることがないようにも、注意が必要です >>82

[58] 再度リダイレクトしないで HTML文書を返す場合、 >>34 以外であっても第三者のスクリプトリダイレクトURL文書中に含まれる credentials にアクセスできてしまいますから、注意が必要です。

[59] 再度リダイレクトしないで HTML文書を返す場合、 そこから第三者の管理する Webサイトへのリンク画像等があると、 Referrer を通じて credentials が漏れる可能性がある >>70 ので、注意が必要です。

[60] HTTPS のページでも、 Referrer は送信されます。

[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 クライアント側で確認が必要です。

[18] コールバックURLには oauth_verifier 引数が追加されてリダイレクトされる URL となりますが、悪意のある第三者が正当な方法で得た oauth_verifier 引数を付けた URL を用意することが可能ですから、 oauth_verifier が有効な値であるかどうかと CSRF であるか否かは無関係です。

[78] 攻撃者は大量の要求クライアントに適当な認可符号を与え、認可鯖にアクセスさせることで、 間接的に認可鯖HTTP接続を枯渇させる DoS攻撃を試みるかもしれません。 認可鯖には攻撃者の情報がほとんど届かず、対策が難しい攻撃です。 クライアントは不適切な認可符号があまりに多い利用者のアクセスを拒むべきかもしれません >>79認可鯖にアクセスする前に state 引数による CSRF の検査を行えば攻撃は多少難しくはなりますが、 攻撃者が事前に認可エンドポイントURLクライアントから得ておけば state の値も得られているわけですから、 防止策として完全ではありません >>79

[80] 普通に使っていれば認可符号が不正になることなどないはずですから (認可符号が発行されてから時間が経っていてタイムアウトしていた場合、 履歴から戻るなどで使用済みの認可符号付きリダイレクトURL に戻ってきた時や資源所有者クライアントの間のネットワークエラーなどで認可符号付きリダイレクトURLに再度アクセスがあった時、 クライアント認可鯖の間のネットワークエラーなどで認可符号が使用済みになった場合や認可鯖に接続できなった場合くらいでしょうか。)、 一定時間内に数回、同じ利用者エージェントからの認可符号でエラーになったことをクライアント内で記憶しておけば良さそうです。
[81] oauth_callback=oob の時は利用者の入力ミスを考慮する必要があります。
[85] Using OAuth 2.0 for Installed Applications - Google Accounts Authentication and Authorization — Google Developers ( 版) <https://developers.google.com/accounts/docs/OAuth2InstalledApp#choosingredirecturi>

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.

[90] Authorize | Content API ( 版) <https://box-content.readme.io/reference#authorize>

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

[91] Manually Build a Login Flow - Facebook Login ( 版) <https://developers.facebook.com/docs/facebook-login/manually-build-a-login-flow>

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.

[92] Using OAuth 2.0 — Fitbit Web API Docs () <https://dev.fitbit.com/docs/oauth2/>

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.

[93] documentation/API.md at master · tootsuite/documentation () <https://github.com/tootsuite/documentation/blob/master/Using-the-API/API.md>

redirect_uris: Where the user should be redirected after authorization (for no redirect, use urn:ietf:wg:oauth:2.0:oob)