仕様書

OAuth 1.0 における scope

[2] OAuth 1.0 は scope のような仕組みが必要なことがよくあるとしつつも、 その方式の標準化には踏み込んでいません >>1。

[4] 各鯖は、それぞれの方法で scope の指定を認めていました。 scope の概念を持たない鯖もありました。

OAuth 2.0 における scope

[14] scope (適用範囲) は、アクセストークンによって資源所有者がアクセスすることをクライアントから認められている資源や操作の範囲を表すものです。 短い ASCII 文字列によって表されます。

[36] scope の値はプログラム的に利用されることを想定しており、 末端利用者に表示することは想定していません >>34。

構文

[7] scope 引数の値は、 U+0020 で区切った認可鯖定義の文字列のリストです >>3, >>33, >>34。 文字列の順序は意味を持ちません >>3, >>34。

  1. 文字列
  2. *
    1. U+0020
    2. 文字列

[9] 各文字列は、印字可能ASCII文字のうち、 U+0020、 U+0022、U+005C を除いたもので構成される1文字以上の列です >>3, >>33, >>34。

  • [10] http://chars.suikawiki.org/set/%24rfc6749:scope-token-char

[53] URL が用いられることがよくありますが、そうしなければならないわけではありません。

[8] 複数の文字列の指定は、それぞれの適用範囲を足していくことを表します >>3。

文脈

クライアントによる指定

[5] OAuth 2.0 クライアントは、認可エンドポイント (認証符号、暗示的承諾型) とトークンエンドポイント (資源所有者合言葉credentials、クライアントcredentials) で要求の scope 引数によってアクセス要求の適用範囲scopeを指定することができます >>3, >>15, >>16, >>19, >>20。

[24] クライアントは、トークンエンドポイントで更新トークンからアクセストークンを得る要求で scope 引数によって取得したいアクセストークンの適用範囲を指定することができます。 ただし、元々資源所有者に承諾された適用範囲以外を指定してはなりません。 またこの引数省略すると、元々資源所有者に承諾された適用範囲を表します。 >>23

[26] クライアントは、必要な最小の適用範囲を求めるべきです >>25。

認可鯖による指定

[6] 認可鯖は、発行したアクセストークンの適用範囲をクライアントに知らせるために応答で scope 引数を指定します >>3。

[18] 認可鯖は、アクセストークンを求められた認可エンドポイントからリダイレクトされるリダイレクトURLの素片識別子の scope 引数によってアクセストークンの適用範囲を指定できます。 クライアントの要求と異なる適用範囲である場合には、 scope 引数を指定しなければなりません。 >>17

[22] 認可鯖は、トークンエンドポイントからのアクセストークンを含む JSON 応答の scope 引数によってアクセストークンの適用範囲を指定できます。 クライアントの要求と異なる適用範囲である場合には、 scope 引数を指定しなければなりません。 >>21

[27] クライアントの要求通りの適用範囲とする時は、 明示しても省略しても構いません。

資源鯖による指定

[35] 資源鯖は、 WWW-Authenticate: Bearer ヘッダーに scope 引数を指定できます >>34。

処理

[11] 認可鯖は、認可鯖の方針や資源所有者の指示、 クライアントの identity に基づき、 クライアントに指定された適用範囲の一部または全部を無視して構いません >>3, >>25。 クライアントが要求した適用範囲と異なるアクセストークンを発行する時は、 応答に scope 引数を指定してアクセストークンの適用範囲を明示しなければなりません >>3。

[30] 資源所有者合言葉credentialsは特に危険であるとの認識から、 利用可能な適用範囲をより限定的にすることを検討するべきです >>29。

[12] クライアントが認可エンドポイントへの要求で scope 引数を指定しなかった時は、予め定義された既定値として処理するか、 妥当でない適用範囲として失敗にしなければなりません >>3。

[13] 認可鯖は適用範囲の要件と既定値を明文化するべきです >>3。

[28] クライアントは、アクセストークンを得た時に scope 引数を確認して、希望した適用範囲がすべて認められたかどうかを調べる必要があります。 一部しか認められなかったとしても、その理由までは示されないので、 クライアントの登録の設定を変更するなど認可鯖依存の方法でクライアントの開発者が手動で操作しなければならない可能性もあります。

メモ

[31] state 引数の値には、クライアントや資源所有者の繊細な情報を平文で含めるべきではありません >>32。

OpenID Connect の scope

[38] OpenID Connect >>37 は OAuth 2.0 の scope の値を規定しています。

[39] openid が指定されていると、 OpenID Connect の実装は OpenID Connect により当該 OAuth 要求を処理することになります。

[40] profile、email、 address、phone の意味が規定されています >>37。

[43] offline_access の意味が規定されています >>42。

[41] OpenID Connect を実装しない場合、これらの値を OpenID Connect が規定する意味に従って解釈する義務はありません。しかし openid という値を OpenID 以外で使用する意味は無いでしょう。またそれ以外の値は将来 OpenID Connect に対応する可能性があるなら、 OpenID Connect と矛盾する意味で使うべきでは無いでしょう。

メモ

[44] Using OAuth 2.0 for Web Server Applications - Google Accounts Authentication and Authorization — Google Developers ( 版) https://developers.google.com/accounts/docs/OAuth2WebServer#incrementalAuth

[45] Cross-client Identity - Google Accounts Authentication and Authorization — Google Developers ( 版) https://developers.google.com/accounts/docs/CrossClientAuth

[46] OAuth 1.0 API Reference - Google Accounts Authentication and Authorization — Google Developers ( 版) https://developers.google.com/accounts/docs/OAuth_ref#Parameters

(required) URL identifying the service(s) to be accessed. The resulting token enables access to the specified service(s) only. Scopes are defined by each Google service; see the service's documentation for the correct value. To specify more than one scope, list each one separated with a space. This parameter is not defined in the OAuth standards; it is a Google-specific parameter.

[47] Google は OAuth 1.0 時代から scope を使っていました >>46。

[50] はてなは OAuth 1.0 で scope 引数を使っていますが、 , 区切りで複数指定できるとしています >>48, >>49。

[52] GitHub は OAuth 2.0 scope で , 区切りとしています。

, が禁止されているわけではないので、仕様違反ではありません。