メインコンテンツまでスキップ

3. プロトコルエンドポイント (Protocol Endpoints)

認可プロセスは、2つの認可サーバーエンドポイント (HTTPエンドポイント) を使用します。

  • 認可エンドポイント (Authorization Endpoint) - クライアントがユーザーエージェントリダイレクション経由でリソースオーナーから認可を取得するために使用されます。
  • トークンエンドポイント (Token Endpoint) - クライアントがアクセストークン (Access Token) のための認可グラント (Authorization Grant) またはリフレッシュトークン (Refresh Token) を交換するために使用されます。

さらに、1つのクライアントエンドポイント (Client Endpoint) があります。

  • リダイレクションエンドポイント (Redirection Endpoint) - 認可サーバーがリソースオーナーのユーザーエージェント経由でクライアントに認可認証情報を含む応答を返すために使用されます。

すべてのエンドポイントが OAuth 認可プロセスで使用されるわけではありません。たとえば、インプリシット許可 (Implicit Grant) フローはトークンエンドポイントを使用しません。一方、リソースオーナーパスワードクレデンシャル許可 (Resource Owner Password Credentials Grant) では認可エンドポイントを使用しません。

エンドポイント URI は、クエリコンポーネントを含めることができます (MAY) (<RFC3986> セクション3で定義されているとおり)。ただし、クエリコンポーネントは本仕様で定義されていないパラメータを含めることはできません (MUST NOT)。認可サーバーとクライアントは、クエリコンポーネントまたは application/x-www-form-urlencoded 形式を使用してパラメータを追加することで、本仕様で定義されているパラメータを含むURIに追加パラメータを含める must 必要があります (MUST)。ただし、リダイレクション URI はこの要件から除外されます。

3.1. 認可エンドポイント (Authorization Endpoint)​

認可エンドポイント (Authorization Endpoint) は、リソースオーナーと対話し、認可を取得するために使用されます。認可サーバーは、最初にリソースオーナーの身元を確認しなければなりません (MUST)。認可サーバーがリソースオーナーの身元を確認する方法 (たとえば、ユーザー名とパスワード、セッションクッキーなど) は、本仕様の範囲外です。

クライアントがリソースオーナーからの認可を取得する手段は、リダイレクションを介するか直接的かに関係なく、認可サーバーの能力、要件、およびセキュリティ考慮事項に従って決定される必要があります。リダイレクションベースのフローを使用する場合、認可サーバーはユーザーエージェント (通常はウェブブラウザ) を介してクライアントとリソースオーナー間の通信を仲介します。

HTTP リダイレクションを介して認可エンドポイントと通信する場合、認可サーバーは TLS を要求しなければなりません (MUST)。エンドポイント URI は <RFC2616> で定義されているとおり、絶対 URI でなければなりません (MUST)。エンドポイント URI は、フラグメントコンポーネントを含めることはできません (MUST NOT)。

認可エンドポイントは、クライアント認証を必要としないため、次のようなセキュリティ脆弱性の影響を受ける可能性があります。

  • リソースオーナーがクライアントを認証できず、悪意のあるクライアントによって騙される可能性がある。
  • リソースオーナーが認可サーバーを認証できず、悪意のある認可サーバーによって騙される可能性がある。

これらの脅威を軽減するために、認可サーバーは、リソースオーナーがクライアントの身元を確認できるようにし (セクション10.12を参照)、TLS を使用して、認可サーバーのエンドポイントの信頼性を保証する必要があります (SHOULD) (セクション1.6およびセクション10.9を参照)。

3.1.1. 応答タイプ (Response Type)​

認可エンドポイント (Authorization Endpoint) は、response_type リクエストパラメータによって決定される、複数の応答タイプをサポートするために使用されます。response_type パラメータ値は、大文字と小文字を区別する空白区切りのリストであり、ASCII [USASCII] 文字のみを使用します。

拡張応答タイプには、追加の値を含めることができます (MAY)。response_type パラメータが認識されない値を含むか、値が欠落している場合、認可サーバーは、セクション4.1.2.1で説明されているエラー応答を返さなければなりません (MUST)。

3.1.2. リダイレクションエンドポイント (Redirection Endpoint)​

認可サーバーがリソースオーナーのユーザーエージェントをクライアントにリダイレクトして認可プロセスを完了した後、認可サーバーはクライアントの登録済みリダイレクション URI (Redirection URI) にリソースオーナーのユーザーエージェントをリダイレクトします。

リダイレクションエンドポイントURI は、次の要件を満たす必要があります (MUST)。

  • 絶対 URI である必要があります (<RFC3986> セクション4.3で定義されているとおり)。
  • リダイレクション URI は、フラグメントコンポーネントを含めることはできません (MUST NOT)。

エンドポイント要求の機密性

リダイレクションエンドポイント (Redirection Endpoint) は、認可プロセスを完了するために使用されるため、クライアント認証情報とアクセストークンを含む可能性があるため、機密性を保つ必要があります (SHOULD)。TLS を使用することが推奨されます (セクション1.6およびセクション10.9を参照)。

登録要件

認可サーバーは、次の場合にリダイレクション URI の登録を要求しなければなりません (MUST)。

  • 公開クライアント (Public Client)
  • 機密クライアント (Confidential Client) がインプリシット許可タイプ (Implicit Grant Type) を使用している場合

認可サーバーは、すべてのクライアントにリダイレクション URI の登録を要求すべきです (SHOULD)。

認可サーバーは、クライアントが複数のリダイレクション URI を登録することを許可すべきです (SHOULD)。登録されたリダイレクション URI の一部が一致しないという想定はしないでください。

リダイレクション URI の登録が必要な場合でも、認可サーバーは、パーシャル リダイレクション URI の登録を許可することができます (SHOULD)。この場合、認可サーバーは、クライアントが提供する完全なリダイレクション URI をリクエストごとに検証しなければなりません (MUST) (セクション3.1.2.3を参照)。

動的設定

リダイレクション URI が登録されていない場合、クライアントは、認可リクエストごとにリダイレクション URI を含めなければなりません (MUST) (redirect_uri パラメータを使用)。

リダイレクション URI が登録されていて、認可リクエストにリダイレクション URI が含まれていない場合、認可サーバーは、登録されたリダイレクション URI を使用しなければなりません (MUST)。

認可リクエストにリダイレクション URI が含まれている場合、認可サーバーは、リクエストされた値が、少なくとも1つの登録されたリダイレクション URI と一致することを検証しなければなりません (MUST)。

無効なエンドポイント

リダイレクション URI の検証中にエラーが発生した場合、認可サーバーは、リソースオーナーに通知し、無効なリダイレクション URI に自動的にリダイレクトしてはなりません (MUST NOT)。

エンドポイントコンテンツ

リダイレクションリクエストは、認可コード (Authorization Code) またはアクセストークン (Access Token) などの機密情報を含む可能性があるため、クライアントは、リダイレクションエンドポイントがサードパーティ (リソースオーナーを除く) に情報を開示しないようにする必要があります (SHOULD)。

3.2. トークンエンドポイント (Token Endpoint)​

トークンエンドポイント (Token Endpoint) は、クライアントがアクセストークン (Access Token) を取得するために使用します。これは、認可グラント (Authorization Grant) またはリフレッシュトークン (Refresh Token) を提示することによって行われます。トークンエンドポイントは、インプリシット許可タイプ (Implicit Grant Type) を除くすべての許可タイプで使用されます (インプリシット許可タイプでは、アクセストークンが認可エンドポイントから直接発行されます)。

トークンエンドポイントの場所とそれにアクセスするための方法は、通常、サービスのドキュメントに記載されています。エンドポイント URI は、クエリコンポーネントを含めることができます (MAY) (<RFC3986> セクション3で定義されているとおり)。ただし、クエリコンポーネントは、追加のパラメータを含めることはできません (MUST NOT)。エンドポイント URI は、フラグメントコンポーネントを含めることはできません (MUST NOT)。

トークンエンドポイントは TLS を要求しなければなりません (MUST)。クライアントは、HTTP POST メソッドを使用してトークンエンドポイントにリクエストを行わなければなりません (MUST)。

トークンエンドポイントへのリクエストに含まれるパラメータは、HTTP リクエストエンティティボディに送信されなければならず (MUST)、application/x-www-form-urlencoded 形式を使用する必要があります (MUST)。

3.2.1. クライアント認証 (Client Authentication)​

機密クライアント (Confidential Client) または他のクライアント認証情報を発行されたクライアントは、トークンエンドポイントでクライアント認証を行わなければなりません (MUST)。クライアント認証は、次の目的で使用されます。

  • クライアントの身元を確認する (クライアント ID のみに基づく)。これは、機密クライアントが不正な許可コードをアクセストークンと交換しようとするのを防ぐために重要です。認可コード送信が安全でないチャネルで行われる場合、または認可サーバーがクライアントが認可コードを取得したことを確認できない場合、認可サーバーはクライアント認証を強制しなければなりません (MUST)。
  • リフレッシュトークン (Refresh Token) をクライアントに結び付ける。リフレッシュトークンがクライアントにバインドされている場合、クライアント認証は、侵害されたリフレッシュトークンを別のクライアントが悪用するのを防ぎます。
  • クライアントがクライアント認証情報を回転させることを可能にする。

クライアントは、各リクエストで複数の認証方法を使用してはなりません (MUST NOT)。パブリッククライアント (Public Client) (クライアント認証情報を発行されていないクライアント) は、トークンエンドポイントに送信するリクエストにクライアント識別子を含めなければなりません (MUST)。

3.3. アクセストークンスコープ (Access Token Scope)​

認可およびトークンエンドポイントにより、クライアントは、scope リクエストパラメータを使用してアクセスリクエストのスコープ (Scope) を指定できます。次に、認可サーバーは、scope 応答パラメータを使用して、発行されたアクセストークンのスコープをクライアントに通知します。

scope パラメータの値は、空白で区切られた、大文字と小文字を区別するスコープ値のリストとして表現されます。スコープ値の定義は、認可サーバーに委ねられています。スコープ値が定義されている場合、認可サーバーは、クライアントが要求したスコープと、実際に付与されたスコープの両方をドキュメント化する必要があります (MUST)。

scope       = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )

認可サーバーは、サポートされているスコープ値を完全にドキュメント化することができます (MAY)。認可サーバーは、クライアントが要求するスコープのいずれか、すべて、またはなしを部分的に許可または拒否することができます (MAY)。リクエストに scope パラメータが含まれていない、または空である場合、認可サーバーは、認可リクエストを拒否するか、デフォルトスコープを適用するか、またはクライアントが要求したスコープを無視しなければなりません (MUST)。認可サーバーは、空のスコープで応答してはなりません (MUST NOT)。

に最終更新