authorization

認可エンドポイント (OAuth)

仕様書

OAuth 1.0 資源所有者認可

[5] OAuth 1.0 クライアントトークンcredentialsを要求するに先立ち、 に対してアクセス要求を認可 (authorize) するよう利用者に求めなければなりません >>3。 この手順を資源所有者認可 (resource owner authorization) といいます。

[6] クライアントは、何らかの方法で広告した資源所有者認可エンドポイントURL を次の通り編集しつつ要求URL としなければなりませんクライアントはその要求URLHTTPリダイレクトその他の方法で資源所有者利用者エージェントにアクセスさせます。 この時使う要求メソッドGET でなければなりません>>3

[7] その URLqueryoauth_token 引数を追加します。

URL query (application/x-www-form-urlencoded)
oauth_token
一時credentials要求からクライアントに提供された一時credentials識別子 (oauth_token 引数の値) とします。 ただし、資源所有者に他の方法で一時credentialsの識別子を示させる方法を用意しているなら、 この引数を省略可能にできます。 >>3

[8] は、その他の引数も規定しても構いません >>3

[91] OAuth 1.0 の拡張である xoauth_response_format 引数を使うと、通常のリダイレクトのかわりに XMLJSON などで結果を POST させることを求めることができます。 JSONP のための xoauth_json_callback 引数も規定されています。

実装例は見当たりません。

[88] Twitterforce_loginscreen_name を規定しています >>87, >>89。いずれも省略可能です。

[81] Googlehd, hl, btmpl を規定していました。いずれも省略可能でした。 >>80

[108] FitbitlocaledisplayrequestCredentials を規定しています >>107

[110] WP-APIwp_scope を規定しています >>109

[116] Dropboxlocaledisable_signup を規定しています >>115

[128] EvernotepreferRegistration 引数を規定しています >>127

[130] UserVoiceguid, sso, scheme を規定しています >>129

[9] 資源所有者認可保安輸送路を使うか否かはに任されていて、 OAuth としては規定されていません >>3

[10] はまず資源所有者identity検証 (verify) しなければなりません。 その後認可要求をどう処理するかはに委ねられています。 >>3

[16] 一般的には、はまず資源所有者がそのWebアプリケーションにおけるアカウントログイン状態にあるか (Cookie認証等で) 確認し、必要ならログイン処理を行います。 次に一時credentialsから調べた OAuth クライアントについての登録情報や、 (あれば) そのWebアプリケーションにおける可能な操作の範囲 (いわゆる scope) など判断に必要な情報を表示し、資源所有者に対して認可するか否かの選択を求めます。 (ログインしていない場合、ログイン認可を同時に確認する実装もあります。)
[18] 既に一部の scope について認可していて、更に追加の scope認可を求められている場合に差分だけ表示して確認を求める実装もあります。 また新たに要求された scope をすべて認可済みの時に、 確認を省略して直ちに HTTPリダイレクトする実装もあります >>21。 ただしその場合はセキュリティー的に問題ないか、資源所有者側の実装者も十分検討する必要があります。 特にクライアントcredentialsが流出している場合には、 資源所有者が気づかないうちにトークンcredentialsを与えてしまうことになるので危険です >>21。無確認でリダイレクトするのは特定の限定された scope のみとするなど、配慮が必要です >>21

[53] CSRF 対策が必要です。

[12] は、資源所有者認可すると判断したら、 一時credentials要求oauth_callback 引数、 あるいはその他の手段で指定されたコールバックURLがあれば、 資源所有者をそこにリダイレクトします。 >>3

[13] コールバックURLquery には次の引数を追加しなければなりません >>3。 既に query があるなら、末尾に追加しなければなりません >>3

URL query
[14] oauth_token
クライアントから受信した一時credentials識別子 >>3
[15] oauth_verifier
検証符号 (verification code) >>3

[111] WP-APIwp_scope 引数も追加します >>109

[117] Dropboxuid 引数も追加します >>115

[20] コールバックURL は不適切な値が指定されるかもしれません。 oauth_callback を参照してください。

[17] は、クライアントコールバックURL が提供しなかった場合には、 検証符号を表示し、資源所有者に対して手動でクライアントに入力するよう指示するべきです >>3

[118] 資源所有者認可資源所有者認可しないことを選択した場合の動作は、 OAuth 仕様としては規定されていません。によりコールバックURL にそのままリダイレクトしたり、別途設定した取り消し時の URLリダイレクトしたりします。クライアント側にリダイレクトしなければならないとの規定もありません。

[119] Dropbox は、コールバックURLnot_approved 引数を追加してリダイレクトします >>115

OAuth 2.0 認可エンドポイント

[2] OAuth 2.0 認可鯖認可エンドポイント (authorization endpoint) は、 資源所有者から認可承諾を得るために使うものです。 認可符号承諾型暗示的承諾型で使います。 >>1

認可エンドポイントへの要求

[22] クライアント認可エンドポイントの位置を知る方法は OAuth 仕様の範囲外ですが、通常はサービスドキュメントにより示されます >>1

[24] 認可エンドポイントでは TLS を使わなければなりません >>1, >>48クライアントRFC 6125 により認可鯖TLS証明書を検証しidentity認証しなければなりません >>48 (HTTPS鯖認証)。

[57] spoofing により認可鯖が攻撃者に入れ替わっている危険性がありますから、 の確認は重要です >>56

[23] 認可エンドポイントURL には application/x-www-form-urlencoded 形式の query を含めても構いません。素片識別子を含んではなりませんquery が含まれる場合には、引数を追加する場合には元の query を残して追加しなければなりません>>1

[37] 認可符号またはアクセストークンを取得するために資源所有者リダイレクトする URL の構築時には、引数URL queryapplication/x-www-form-urlencoded 形式で指定します >>36, >>44。次の引数があります。

URL query (application/x-www-form-urlencoded)
[68] response_type
認可符号の取得なら codeアクセストークンの取得なら token でなければなりません >>36, >>44OpenID Connect 暗示フローなら id_token token または id_token としなければなりません >>73
[69] client_id
クライアント識別子を指定しなければなりません >>36, >>44
[70] redirect_uri
リダイレクトURLを指定できます >>36, >>44
[71] scope
適用範囲を指定できます >>36, >>44
[72] state
局所状態を表す値を指定するべきです >>36, >>44
code_challenge
PKCE
code_challenge_method
PKCE

[67] OpenID Connect は、次の引数を規定しています。いくつかは必須です。

[75] GoogleOpenID 2.0 からの移行のための独自の openid.realm と独自の hdaccess_typeinclude_granted_scopes を追加しています >>76approval_prompt >>77 という引数もあるようです。

[83] Azureresourcedomain_hint を追加しています >>82

[93] Spotifyshow_dialog を追加しています >>92

[95] Slackteam を追加しています >>94

[97] redditduration を追加しています >>96

[99] Salesforcecode_challenge, immediate を追加しています >>98

[103] SurveyMonkeyapi_key を追加しています >>102

[106] Viadeolang, cancel_url を追加しています >>105

[113] Yahoo!language を追加しています >>112

[121] Dropboxforce_reapprovedisable_signup を追加しています >>120

[74] OpenID ConnectURL query を直接使うのではなく、 JWT 要求オブジェクトによって間接的に指定する方法も規定しています。

[31] クライアントは、要求response_type 引数code (認可符号承諾型) か token (暗示的承諾型) か拡張の承諾型を表す値のいずれかを指定しなければなりません >>1

[29] 要求引数は、複数指定してはなりません >>1

[25] 認可鯖は、認可エンドポイントにおいて GET 要求メソッドに対応しなければなりませんPOST 要求メソッドに対応しても構いません。 >>1

[132] 楽天GETPOST に対応しています >>131

認可エンドポイントでの処理

[4] 認可鯖は、まず資源所有者認証 (identity検証 (verify) ) しなければなりません >>1, >>36認可鯖資源所有者認証する方法は、 OAuth 仕様の範囲外で、利用者名合言葉によるログインであれ、 セッションクッキーであれ、任意の方法を使うことができます >>1

[52] 認可エンドポイントでは CSRF 対策を行わなければなりません >>48

[32] 認可鯖は、 response_type 引数が指定されていない時や理解できない時は、 誤りを返さなければなりません >>1

[35] 認可鯖はすべての必須引数が指定されており、妥当であることを確認します。 >>36, >>44

[26] 要求引数で値のないものは、指定されなかったものとして扱わなければなりません >>1

[27] 値がないというのは、 application/x-www-form-urlencoded= が含まれない組のことでしょうか? 空文字列と区別されるということでしょうか?

[28] 認可鯖は、認識できない引数を無視しなければなりません >>1

[38] 認可鯖は、資源所有者に尋ねるなり、その他何らかの手段を使うなりして、 資源所有者から認可するかの決定を得ます >>36, >>44

リダイレクトエンドポイントへのリダイレクト

[34] 認可鯖は、資源所有者がアクセス要求を承諾したら、 資源所有者クライアント (のリダイレクトエンドポイント) へとリダイレクトにより戻します >>1, >>36, >>44

[39] 認可符号を求められている場合で資源所有者認可が得られた場合には、 リダイレクトURLquery には application/x-www-form-urlencoded 形式で次の引数を追加します >>36

URL query (application/x-www-form-urlencoded)
code
認可鯖が生成した認可符号を指定しなければなりません
state
クライアント認可の要求に state 引数を指定していれば、まったく同じ値を指定しなければなりません

[84] Azure は更に admin_consentsession_state を追加しています >>82

[45] アクセストークンを求められている場合で資源所有者認可が得られた場合には、 リダイレクトURL素片識別子には application/x-www-form-urlencoded 形式で次の引数を追加します >>33

素片識別子 (application/x-www-form-urlencoded)
access_token
認可鯖が発行したアクセストークンを指定しなければなりません >>33
token_type
発行したトークンの種類を指定しなければなりません >>33
expires_in
アクセストークン寿命単位で指定するべきです >>33
scope
クライアントが要求した適用範囲アクセストークン適用範囲が異なるなら、指定しなければなりません。同じ場合も指定できます。 >>33
state
クライアント認可の要求に state 引数を指定していれば、まったく同じ値を指定しなければなりません >>33
id_token
OpenID Connect の場合は指定しなければなりません

[46] この場合更新トークンを発行してはなりません >>33

[100] Salesforce は独自の id, instance_url, issued_at, signature を指定するようです。 >>101

[114] Yahoo! は独自の xoauth_yahoo_guid を指定するようです >>112

[43] 資源所有者がアクセス要求を拒んだ場合やリダイレクトURLの欠如や非妥当ではない点で要求に問題がある場合には、 認可符号を求められているならリダイレクトURLqueryアクセストークンを求められているならリダイレクトURL素片識別子application/x-www-form-urlencoded 形式で次の引数を追加します >>41, >>33

URL query/素片識別子 (application/x-www-form-urlencoded)
error
誤り符号を指定しなければなりません
error_description
人間可読誤りの説明を指定して構いません。
error_uri
人間可読誤りの説明を含むWebページURL を指定して構いません。
state
クライアント認可の要求に state 引数を指定していれば、まったく同じ値を指定しなければなりません

[30] 応答引数は、複数指定してはなりません >>1

[78] OpenID による拡張である要求request_mode 引数は、 URL query素片識別子、あるいは application/x-www-form-urlencoded のいずれの方法で応答引数を返すべきかを指定するものです。

[79] Google の拡張はリダイレクトURLの指定により素片識別子でなく URL query を使うことを求めたり、リダイレクトのかわりに認可符号を含む HTML文書を表示させること、を閉じることを求めるHTML文書を表示させることを指定できるようにしています。

[42] リダイレクトURLが指定されていない場合、非妥当な場合、一致しない場合や、 クライアント識別子が指定されない場合や非妥当な場合には、 資源所有者誤りを知らせるべきであり、 自動的に非妥当リダイレクトURLリダイレクトしてはなりません>>1, >>41, >>33

[51] OAuth 1.0oauth_callback=oob に相当する仕組みは用意されていません。他の承諾型を使うなどするべきです。

資源所有者に対する認可の確認画面

[122] 認可鯖認可するか尋ねるに当って HTTP クライアントが当該サービス上のどの資源所有者であるか認証する必要があります。この認証Cookie認証その他当該サービスの従来の方式によるもので、 OAuth の仕様の範囲外です。

[123] HTTP クライアントCookieを有していないなど認証されない状態でアクセスしてきている場合には、 ログイン画面へ誘導する、あるいは認可と同時にログインを求める、 認可と同時に credentials の入力を求めるといった方法でどの資源所有者か特定する必要が生じます。

[124] そのため、資源所有者認可ステップは複数回の認可鯖-HTTPクライアント (資源所有者) 間のやり取りで構成される場合があります。

[125] 認可鯖のサービス上のアカウントを既に保有していない HTTP クライアントからのアクセスだった場合には、 新規のアカウント登録を求める認可鯖もあります。そのような利用方法を認めていない場合や、 認めるかどうかを OAuth クライアントに指定させる場合もあります。

[126] 特にこの場合には次のステップに進むまで時間がかかることがあり、 OAuth 1.0 一時credentialsの有効期限を超過する虞もあります。

[11] 要求されたアクセスを認可するかどうか OAuth 1.0 資源所有者に尋ねるときには、 一時credentialsクライアントidentity との関連付けに基づき、アクセスを要求しているクライアントについての情報を表示するべきです。 表示に際しては、その情報が検証 (verify) されたものかどうか示すべきです>>3

[50] OAuth 2.0 認可鯖は、資源所有者認証を明示的に行った上で、 クライアントや要求されている認可適用範囲寿命についての情報を資源所有者に提供するべきです。 現在のクライアントに照らしてその情報を確認し認可するかどうかを判断するのは資源所有者の責任です。 >>48

[59] 認可鯖資源所有者に対して認可適用範囲を理解可能な形で説明し、 必要以上の権限をクライアントに与えてしまわないように注意する必要があります >>58

[61] 認可鯖は、既に過去に認可を得ている場合には、 資源所有者に対する確認を省いて自動的にリダイレクトしてクライアントに戻すことができます >>60

[49] OAuth 2.0 認可鯖は、繰り返される認可の要求について、 クライアント認証が行われる場合やその他の手段で本来のクライアントから求められていると確認できる場合を除き、 (明示的に資源所有者が操作せずに) 自動的に処理するべきではありません >>48, >>62。 また自動承認する適用範囲を限定することも好ましいかもしれません >>60

[86] Twitter その他 >>85, >>104, >>107OAuthログイン認可資源所有者認可エンドポイントを別にしており、 後者では自動リダイレクトはしないとしています。

[19] この確認画面はクリックジャッキング対策が必要です >>63。 またWebブラウザー以外で表示したり、アドレスバーを隠したりするのはフィッシングの疑いを拭い去れないため、避けるべきと考えられています。

[47] ネイティブアプリケーションは埋め込みブラウザー (アプリ内ブラウザー) ではなく外部のブラウザーを使うべきです >>48

[55] 不正なクライアントは埋め込みブラウザーを使って、 資源所有者認証で入力された利用者名合言葉を盗む >>54 など、 不適切な動作をするかもしれません。 (認可に限らず) 埋め込みブラウザーによってフィッシングサイトを表示するなどの危険性があります。 利用者に啓蒙する、アプリマーケットで審査するといった対策は挙げられてはいますが >>54OAuth の仕様の内外を問わず、根本的に解決するのは難しい問題です。

[65] また不正なクライアントは埋め込みブラウザーを使って資源所有者に無断で機械的に認可 (認可鯖フォームを勝手に POST など) する >>64 こともあるかもしれません。 CAPTCHA などにより資源所有者が実際に操作していることを確認したり、 認可後に電子メールなどで資源所有者に通知したりする対策が必要かもしれません >>64

[66] Final: OpenID Connect Core 1.0 incorporating errata set 1 ( 版) <http://openid.net/specs/openid-connect-core-1_0.html#Terminology>

Authorization Request

OAuth 2.0 Authorization Request as defined by [RFC6749].

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

Any attempt to embed the OAuth 2.0 authentication page will result in your application being banned from the Fitbit API.

For security consideration, the OAuth 2.0 authorization page must be presented in a dedicated browser view. Fitbit users can only confirm they are authenticating with the genuine Fitbit.com site if they have the tools provided by the browser, such as the URL bar and Transport Layer Security (TLS) certificate information.

For native applications, this means the authorization page must open in the default browser. Native applications can use custom URL schemes as redirect URIs to redirect the user back from the browser to the application requesting permission.

iOS applications may use the SFSafariViewController class instead of app switching to Safari. Use of the WKWebView or UIWebView class is prohibited.

Android applications may use Chrome Custom Tabs instead of app switching to the default browser. Use of WebView is prohibited.

For web applications, do not use an iframe. Web applications may use a pop-up window, so long as the URL bar is visible.

[134] 認証と認可 | Cacoo Developer API | Nulab ( ()) <https://developer.nulab-inc.com/ja/docs/cacoo/auth/#2-oauth>

OAuth での認証からアカウント登録を行う場合、以下のパラメータを Authorize の URL に指定することで、アカウント登録フォームへの事前入力ができます。

Name Description

signup.mailAddress アカウントのメールアドレス

signup.nickname アカウントのニックネーム