[5] OAuth 1.0 クライアントは鯖にトークンcredentialsを要求するに先立ち、 鯖に対してアクセス要求を認可するよう利用者に求めなければなりません >>3。 この手順を資源所有者認可といいます。
[6] クライアントは、何らかの方法で鯖が広告した資源所有者認可のエンドポイントの
URL を次の通り編集しつつ要求URL としなければなりません。
クライアントはその要求URLをHTTPリダイレクトその他の方法で資源所有者の利用者エージェントにアクセスさせます。
この時使う要求メソッドは GET でなければなりません。 >>3
[7] その URL の query に oauth_token 引数を追加します。application/x-www-form-urlencoded)oauth_tokenoauth_token 引数の値) とします。
ただし、鯖は資源所有者に他の方法で一時credentialsの識別子を示させる方法を用意しているなら、
この引数を省略可能にできます。 >>3
[91] OAuth 1.0 の拡張である xoauth_response_format
引数を使うと、通常のリダイレクトのかわりに XML や JSON
などで結果を POST させることを求めることができます。
JSONP のための xoauth_json_callback 引数も規定されています。
[88] Twitter は force_login、screen_name
を規定しています >>87, >>89。いずれも省略可能です。
[81] Google は hd, hl, btmpl
を規定していました。いずれも省略可能でした。 >>80
[108] Fitbit は locale、display、
requestCredentials を規定しています >>107。
[110] WP-API は wp_scope を規定しています >>109。
[116] Dropbox は locale、disable_signup
を規定しています >>115。
[128] Evernote は preferRegistration 引数を規定しています
>>127。
[130] UserVoice は guid, sso, scheme
を規定しています >>129。
[9] 資源所有者認可で保安輸送路を使うか否かは鯖に任されていて、 OAuth としては規定されていません >>3。
[10] 鯖はまず資源所有者の identity を検証しなければなりません。 その後認可要求をどう処理するかは鯖に委ねられています。 >>3
[12] 鯖は、資源所有者が認可すると判断したら、
一時credentials要求の oauth_callback 引数、
あるいはその他の手段で指定されたコールバックURLがあれば、
資源所有者をそこにリダイレクトします。 >>3
[13] コールバックURL の query には次の引数を追加しなければなりません >>3。
既に query があるなら、末尾に追加しなければなりません >>3。
[111] WP-API は wp_scope 引数も追加します >>109。
[117] Dropbox は uid 引数も追加します >>115。
[17] 鯖は、クライアントがコールバックURL が提供しなかった場合には、 検証符号を表示し、資源所有者に対して手動でクライアントに入力するよう指示するべきです >>3。
[118] 資源所有者認可で資源所有者が認可しないことを選択した場合の動作は、 OAuth 仕様としては規定されていません。鯖によりコールバックURL にそのままリダイレクトしたり、別途設定した取り消し時の URL にリダイレクトしたりします。クライアント側にリダイレクトしなければならないとの規定もありません。
[119] Dropbox は、コールバックURLに not_approved
引数を追加してリダイレクトします >>115。
[2] OAuth 2.0 認可鯖の認可エンドポイントは、 資源所有者から認可承諾を得るために使うものです。 認可符号承諾型と暗示的承諾型で使います。 >>1
[22] クライアントが認可エンドポイントの位置を知る方法は OAuth 仕様の範囲外ですが、通常はサービスのドキュメントにより示されます >>1。
[24] 認可エンドポイントでは TLS を使わなければなりません >>1, >>48。 クライアントは RFC 6125 により認可鯖のTLS証明書を検証し鯖の identity を認証しなければなりません >>48 (HTTPS鯖認証)。
[23] 認可エンドポイントの URL には application/x-www-form-urlencoded
形式の query を含めても構いません。素片識別子を含んではなりません。
query が含まれる場合には、引数を追加する場合には元の query
を残して追加しなければなりません。 >>1
[37] 認可符号またはアクセストークンを取得するために資源所有者をリダイレクトする URL
の構築時には、引数を URL query に application/x-www-form-urlencoded
形式で指定します >>36, >>44。次の引数があります。application/x-www-form-urlencoded)response_typecode、
アクセストークンの取得なら token でなければなりません
>>36, >>44。OpenID Connect 暗示フローなら
id_token token または id_token
としなければなりません >>73。client_idredirect_uriscopestatecode_challengecode_challenge_method
[67] OpenID Connect は、次の引数を規定しています。いくつかは必須です。
[75] Google は OpenID 2.0 からの移行のための独自の openid.realm
と独自の hd、access_type、
include_granted_scopes を追加しています >>76。
approval_prompt >>77 という引数もあるようです。
[83] Azure は resource と domain_hint
を追加しています >>82。
[93] Spotify は show_dialog を追加しています >>92。
[95] Slack は team を追加しています >>94。
[97] reddit は duration を追加しています >>96。
[99] Salesforce は code_challenge, immediate
を追加しています >>98。
[103] SurveyMonkey は api_key を追加しています >>102。
[106] Viadeo は lang, cancel_url
を追加しています >>105。
[113] Yahoo! は language を追加しています >>112。
[121] Dropbox は force_reapprove と disable_signup
を追加しています >>120。
[74] OpenID Connect は URL query を直接使うのではなく、 JWT 要求オブジェクトによって間接的に指定する方法も規定しています。
[31] クライアントは、要求の response_type
引数で code (認可符号承諾型) か
token (暗示的承諾型) か拡張の承諾型を表す値のいずれかを指定しなければなりません >>1。
[25] 認可鯖は、認可エンドポイントにおいて GET
要求メソッドに対応しなければなりません。 POST
要求メソッドに対応しても構いません。 >>1
[4] 認可鯖は、まず資源所有者を認証 (identity を検証) しなければなりません >>1, >>36。 認可鯖が資源所有者を認証する方法は、 OAuth 仕様の範囲外で、利用者名と合言葉によるログインであれ、 セッションクッキーであれ、任意の方法を使うことができます >>1。
[52] 認可エンドポイントでは CSRF 対策を行わなければなりません >>48。
[32] 認可鯖は、 response_type 引数が指定されていない時や理解できない時は、
誤りを返さなければなりません >>1。
[35] 認可鯖はすべての必須の引数が指定されており、妥当であることを確認します。 >>36, >>44
[26] 要求の引数で値のないものは、指定されなかったものとして扱わなければなりません >>1。
[28] 認可鯖は、認識できない引数を無視しなければなりません >>1。
[38] 認可鯖は、資源所有者に尋ねるなり、その他何らかの手段を使うなりして、 資源所有者から認可するかの決定を得ます >>36, >>44。
[34] 認可鯖は、資源所有者がアクセス要求を承諾したら、 資源所有者をクライアント (のリダイレクトエンドポイント) へとリダイレクトにより戻します >>1, >>36, >>44。
[39] 認可符号を求められている場合で資源所有者の認可が得られた場合には、
リダイレクトURLの query には
application/x-www-form-urlencoded
形式で次の引数を追加します >>36。application/x-www-form-urlencoded)
[84] Azure は更に admin_consent と
session_state を追加しています >>82。
[45] アクセストークンを求められている場合で資源所有者の認可が得られた場合には、
リダイレクトURLの素片識別子には
application/x-www-form-urlencoded
形式で次の引数を追加します >>33。application/x-www-form-urlencoded)access_tokentoken_typeexpires_inscopestatestate
引数を指定していれば、まったく同じ値を指定しなければなりません >>33。id_token
[100] Salesforce は独自の id, instance_url,
issued_at, signature を指定するようです。 >>101
[114] Yahoo! は独自の xoauth_yahoo_guid
を指定するようです >>112。
[43] 資源所有者がアクセス要求を拒んだ場合やリダイレクトURLの欠如や非妥当ではない点で要求に問題がある場合には、
認可符号を求められているならリダイレクトURLの query、
アクセストークンを求められているならリダイレクトURL の素片識別子に
application/x-www-form-urlencoded
形式で次の引数を追加します >>41, >>33。application/x-www-form-urlencoded)
[78] OpenID による拡張である要求の request_mode 引数は、
URL query と素片識別子、あるいは application/x-www-form-urlencoded
のいずれの方法で応答の引数を返すべきかを指定するものです。
[79] Google の拡張はリダイレクトURLの指定により素片識別子でなく URL query を使うことを求めたり、リダイレクトのかわりに認可符号を含む HTML文書を表示させること、窓を閉じることを求めるHTML文書を表示させることを指定できるようにしています。
[42] リダイレクトURLが指定されていない場合、非妥当な場合、一致しない場合や、 クライアント識別子が指定されない場合や非妥当な場合には、 資源所有者に誤りを知らせるべきであり、 自動的に非妥当なリダイレクトURLにリダイレクトしてはなりません。 >>1, >>41, >>33
[122] 認可鯖は認可するか尋ねるに当って HTTP クライアントが当該サービス上のどの資源所有者であるか認証する必要があります。この認証は Cookie認証その他当該サービスの従来の方式によるもので、 OAuth の仕様の範囲外です。
[123] HTTP クライアントがCookieを有していないなど認証されない状態でアクセスしてきている場合には、 ログイン画面へ誘導する、あるいは認可と同時にログインを求める、 認可と同時に credentials の入力を求めるといった方法でどの資源所有者か特定する必要が生じます。
[125] 認可鯖のサービス上のアカウントを既に保有していない HTTP クライアントからのアクセスだった場合には、 新規のアカウント登録を求める認可鯖もあります。そのような利用方法を認めていない場合や、 認めるかどうかを OAuth クライアントに指定させる場合もあります。
[11] 要求されたアクセスを認可するかどうか OAuth 1.0 鯖が資源所有者に尋ねるときには、 一時credentialsとクライアントの identity との関連付けに基づき、アクセスを要求しているクライアントについての情報を表示するべきです。 表示に際しては、その情報が検証されたものかどうか示すべきです。 >>3
[50] OAuth 2.0 認可鯖は、資源所有者の認証を明示的に行った上で、 クライアントや要求されている認可の適用範囲や寿命についての情報を資源所有者に提供するべきです。 現在のクライアントに照らしてその情報を確認し認可するかどうかを判断するのは資源所有者の責任です。 >>48
[59] 認可鯖は資源所有者に対して認可の適用範囲を理解可能な形で説明し、 必要以上の権限をクライアントに与えてしまわないように注意する必要があります >>58。
[61] 認可鯖は、既に過去に認可を得ている場合には、 資源所有者に対する確認を省いて自動的にリダイレクトしてクライアントに戻すことができます >>60。
[49] OAuth 2.0 認可鯖は、繰り返される認可の要求について、 クライアント認証が行われる場合やその他の手段で本来のクライアントから求められていると確認できる場合を除き、 (明示的に資源所有者が操作せずに) 自動的に処理するべきではありません >>48, >>62。 また自動承認する適用範囲を限定することも好ましいかもしれません >>60。
[19] この確認画面はクリックジャッキング対策が必要です >>63。 またWebブラウザー以外で表示したり、アドレスバーを隠したりするのはフィッシングの疑いを拭い去れないため、避けるべきと考えられています。
[47] ネイティブアプリケーションは埋め込みブラウザー (アプリ内ブラウザー) ではなく外部のブラウザーを使うべきです >>48。
[55] 不正なクライアントは埋め込みブラウザーを使って、 資源所有者の認証で入力された利用者名と合言葉を盗む >>54 など、 不適切な動作をするかもしれません。 (認可に限らず) 埋め込みブラウザーによってフィッシングサイトを表示するなどの危険性があります。 利用者に啓蒙する、アプリマーケットで審査するといった対策は挙げられてはいますが >>54、 OAuth の仕様の内外を問わず、根本的に解決するのは難しい問題です。
[65] また不正なクライアントは埋め込みブラウザーを使って資源所有者に無断で機械的に認可
(認可鯖のフォームを勝手に POST など) する >>64
こともあるかもしれません。 CAPTCHA などにより資源所有者が実際に操作していることを確認したり、
認可後に電子メールなどで資源所有者に通知したりする対策が必要かもしれません >>64。
Authorization Request
OAuth 2.0 Authorization Request as defined by [RFC6749].
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.
OAuth での認証からアカウント登録を行う場合、以下のパラメータを Authorize の URL に指定することで、アカウント登録フォームへの事前入力ができます。
Name Description
signup.mailAddress アカウントのメールアドレス
signup.nickname アカウントのニックネーム
xoauth_response_format参照。