2.1. Authorization Request (認可リクエスト)

2.1. Authorization Request (認可リクエスト)

認可エンドポイント (authorization endpoint) への認可リクエストで resource パラメーターが用いられる場合, アクセスが要求されている保護リソースの識別を示す. アクセストークンが implicit flow (OAuth 2.0 [RFC6749] 第 4.2 節) により認可エンドポイントから直接返される場合, 要求されたリソースはそのアクセストークンに適用される. code flow ([RFC6749] 第 4.1 節) で認可エンドポイントから認可グラント (authorization grant) の中間表現 (認可コード) が返される場合, 要求されたリソースは完全な認可グラントに適用される.

JSON Web Token (JWT) として送られる認可リクエスト, 例えば JWT Secured Authorization Request (JWT セキュア認可リクエスト) [JWT-SAR] を用いる場合, 単一の resource パラメーター値は JSON 文字列として表され, 複数の値は文字列の配列として表される.

クライアントが認可要求時に resource パラメーターを省略した場合, 認可サーバーは特定リソースなしでリクエストを処理するか, 事前定義のデフォルトリソース値を用いてもよい. あるいは, 認可サーバーはクライアントにアクセスを意図するリソースの指定を要求し, パラメーターを省略したリクエストを invalid_target エラーで失敗させてもよい. 認可サーバーはこのデータを, ユーザにクライアントが代理でアクセスするリソースを通知し, ポリシーを適用し (例: 不明なリソースにより拒否), 後続のアクセストークンリクエストで使用できるリソース集合を決定するために用いてもよい.

認可サーバーが提供された値を解析できないかリソースを受け入れられない場合, error パラメーターの値としてエラーコード invalid_target を用いたエラー応答でリクエストを拒否すべきであり, error_description でエラー理由に関する追加情報を提供してもよい.

図 1 に, クライアントが認可サーバーに https://api.example.com/app/ で使用するアクセストークンを求めていることを伝える認可リクエストの例を示す (表示のための追加の改行とインデント).

GET /as/authorization.oauth2?response_type=token
   &client_id=example-client
   &state=XzZaJlcwYew1u0QBrRv_Gw
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &resource=https%3A%2F%2Fapi.example.com%2Fapp%2F HTTP/1.1
Host: authorization-server.example.com

図 1: Implicit Flow 認可リクエスト

図 2 に, code レスポンスタイプを用い, リソースオーナーの連絡先とカレンダーデータへ https://cal.example.com/ と https://contacts.example.com/ でアクセスを要求する認可リクエストの例を示す (表示のための追加の改行とインデント).

GET /as/authorization.oauth2?response_type=code
   &client_id=s6BhdRkqt3
   &state=tNwzQ87pC6llebpmac_IDeeq-mCR2wLDYljHUZUAWuI
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &scope=calendar%20contacts
   &resource=https%3A%2F%2Fcal.example.com%2F
   &resource=https%3A%2F%2Fcontacts.example.com%2F HTTP/1.1
Host: authorization-server.example.com

図 2: Code Flow 認可リクエスト