> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-docs-event-stream-action-templates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# OAuth 2.0の認可フレームワーク

> Auth0がOAuth 2.0の認可フレームワークとどのように動作するのかを説明します。

<Card title="概要">
  重要なコンセプト

  * Auth0はInternet Engineering Task Force（IETF）によって立案されたOAuth 2.0プロトコルをサポートしている
  * OAuth 2.0仕様のロール、付与タイプ（またはワークフロー）とエンドポイントを理解する
</Card>

[OAuth 2.0](https://tools.ietf.org/html/rfc6749)の認可フレームワークは、ユーザーがサードパーティのWebサイトにアクセスしたり、アプリケーションがユーザーの保護されたリソースにアクセスしたりする際に、長期有効な資格情報や身元さえ不必要に公開されないようにするプロトコルです。

<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=oath2" tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集の表示">OAuth</Tooltip>は認可レイヤーを導入して、役割をクライアントとリソース所有者で区別しています。OAuthでは、リソースがリソース所有者に管理され、リソースサーバーにホストされている場合​、クライアントがそのリソースに対してアクセスを要求すると、リソース所有者とは異なるセットの資​格情報が発行されます。クライアントは保護されたリソースへのアクセスに、リソース所有者の資格情報を使用するのではな​く、アクセストークンという、特定のスコープ、有効期限、その他のアクセスに関する属性を示す文字列を取得します。アクセストークンは、リソース所有者の承認を得た上で、認可サーバーによってサードパーティのク​ライアントに対して発行されます。そして、クライアントはこのアクセストークンを使って、リソースサーバーがホストしている保護さ​れたリソースにアクセスします。

Auth0は、APIの認可についてアクセストークンを[JSON Web Token（JWT）形式](/docs/ja-jp/secure/tokens/json-web-tokens/json-web-token-structure)で生成します。アクセストークンが示すアクセス権の範囲は、OAuthの用語では、[スコープ](/docs/ja-jp/get-started/apis/scopes)として知られています。アプリケーションがAuth0で認証する際には、必要なスコープを指定します。スコープがユーザーによって認可されると、アクセストークンに認可されたスコープが含められます。

## ロール

OAuth 2.0のフローには以下のロールがあります。

* **<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-jp/glossary?term=resource-owner" tip="リソース所有者: 保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。" cta="用語集の表示">Resource Owner</Tooltip>（リソース所有者）** ：保護されたリソースへのアクセスを付与できるエンティティ。大抵の場合、エンドユーザーです。
* **<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-2" href="/docs/ja-jp/glossary?term=resource-server" tip="リソースサーバー: 保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースの要求を受け入れ、応答します。" cta="用語集の表示">Resource Server</Tooltip>（リソースサーバー）** ：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。
* **Client （クライアント）** ：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。
* **<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-3" href="/docs/ja-jp/glossary?term=authorization-server" tip="認可サーバー: ユーザーによるアクセスの限界を定義するために使用される集中管理型サーバー。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集の表示">Authorization Server</Tooltip>（認可サーバー）** ：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この例では、Auth0です。

## 付与タイプ

OAuth 2.0はアクセストークンの取得に4つのフローを定義しています。これらのフローは付与タイプと呼ばれています。[どのフローが状況に適しているかを決める](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)際に、考慮されるのは主にアプリケーションタイプです。

* [認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)：サーバー上で実行されるWebアプリで使用されます。これは、[Proof Key for Code Exchange（PKCE）技術](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)を使用するモバイルアプリでも使用されます。
* [フォームPOSTによる暗黙フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)：ユーザーのブラウザー上で実行されるJavaScript中心のアプリ（シングルページアプリケーション）で使用されます。
* [リソース所有者のパスワードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow)：高信頼性アプリで使用されます。
* [クライアントの資格情報フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow)：マシンツーマシンの通信で使用されます。

仕様では、追加の付与タイプを定義する拡張メカニズムも提供されています。付与タイプそれぞれの仕組みと使用するべき状況については、「[認証と認可フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow)」を参照してください。

## エンドポイント

OAuth 2.0は、`/authorize`エンドポイントおよび`/oauth/token`エンドポイントの2つのエンドポイントを使用します。

### 認可エンドポイント

`/authorize`エンドポイントは、リソース所有者とのやり取りや、保護されたリソースにアクセスするための認可の取得に使用されます。たとえば、Googleアカウントを使ってあるサービスにログインしたいとします。まず、（まだログインしていない場合）認証するために、サービスがGoogleにリダイレクトします。同意の画面が表示され、メールアドレスやコンタクトリストなどのデータ（保護されたリソース）にアクセスすることをサービスに許可するよう求められます。

`/authorize`エンドポイントの要求パラメーターは次のとおりです。

| パラメーター          | 説明                                                                                                                                                                                                                                                                    |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `response_type` | どの付与を実行するか認可サーバーに指示します。                                                                                                                                                                                                                                               |
| `response_mode` | （任意）認可要求の結果の形式を指定します。値：<br />- `query`：認可コード付与の場合です。`302 Found`はリダイレクトをトリガーします。<br />- `fragment`：暗黙付与の場合です。`302 Found`はリダイレクトをトリガーします。<br />- `form_post`：`200 OK`と、HTMLフォームに隠しパラメーターとして埋め込まれた応答パラメーターが入ります。<br />- `web_message`：サイレント認証の場合です。HTML5 Webメッセージを使用します。 |
| `client_id`     | 認可を求めるアプリケーションのIDです。                                                                                                                                                                                                                                                  |
| `redirect_uri`  | URLを含みます。このエンドポイントから正常な応答を受け取ると、このURLにリダイレクトされます。                                                                                                                                                                                                                     |
| `scope`         | アプリケーションに必要な権限をスペース区切りで列挙します。                                                                                                                                                                                                                                         |
| `state`         | セキュリティ目的で使用される不透明な値です。この要求パラメーターが要求に設定されている場合は、`redirect_uri`の一部としてアプリケーションに返されます。                                                                                                                                                                                    |
| `connection`    | パスワードレス接続の接続タイプを指定します。                                                                                                                                                                                                                                                |

アプリケーションがユーザーを認証するために`/authorize`エンドポイントを最初に呼び出すときに、カスタムクエリパラメーターを構成できます。カスタムクエリパラメーターを使用すると、ユニバーサルログインエクスペリエンスのページテンプレートに追加でコンテキストを提供することができます。

`connection`パラメータを使用するには、ID Firstを有効にしてください。`connection`パラメーターおよびユニバーサルログインエクスペリエンスに関する詳細については、「[ユニバーサルログインのパスワードレス](/docs/ja-jp/authenticate/passwordless/passwordless-with-universal-login)」を参照してください。

`ext-`のプレフィックスのあるクエリパラメーターは、自動的に[ページテンプレートのコンテキスト](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates#custom-query-parameters)に表示されます。

このエンドポイントは認可コードと暗黙の付与タイプに使用されます。発行する証明書の種類に影響するため、認可サーバーはアプリケーションが使いたい付与タイプを知る必要があります。

* 認可コード付与の場合、認可サーバーは認可コードを発行します（その後、それが`/oauth/token`エンドポイントでアクセストークンと交換できます）。
* 暗黙的付与の場合、認可サーバーはアクセストークンを発行します。このトークンは不透明な文字列（または、Auth0の実装では<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-3" href="/docs/ja-jp/glossary?term=json-web-token" tip="JSON Web Token（JWT）: 二者間のクレームを安全に表現するために使用される標準IDトークン形式（および多くの場合、アクセストークン形式）。" cta="用語集の表示">JWT</Tooltip>）で、だれがどの許可（スコープ）をどのアプリケーションに対して保持するのかを示します。

使用する付与タイプを認可サーバーに伝えるには、`response_type`要求パラメーターを以下のように使用します。

* 認可コード付与の場合には`response_type=code`を使用して認可コードを含めます。
* 暗黙的付与の場合には`response_type=token`を使用してアクセストークンを含めます。別の方法としては、`response_type=id_token token`を使用してアクセストークンとIDトークンの両方を含めます。

IDトークンはJWTで、ログインしたユーザーについての情報が含まれています。<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-0" href="/docs/ja-jp/glossary?term=openid" tip="OpenID: アプリケーションがログイン情報を収集および保存することなくにユーザーのIDを検証できるようにする認証用のオープン標準。" cta="用語集の表示">OpenID</Tooltip> Connect（OIDC）によって導入されました。

[OAuth 2.0 Multiple Response Type Encoding Practicesという仕様](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html)には、認可要求の結果をどのような形式にするかを指定するパラメーターが追加されています。このパラメーターは`response_mode`と呼ばれています。任意のパラメーターで、以下の値を指定することができます。

| 値             | 説明                                                                                                                                                                                                                                                                                                                                                                                                    |
| ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `query`       | 認可コード付与のデフォルト値です。成功応答は`302 Found`で、`redirect_uri`へのリダイレクトをトリガーします。応答パラメーターは、`Location`ヘッダー内にある`redirect_uri`のクエリコンポーネント（`?`に後続の部分）に埋め込まれます。<br />例：<br />`HTTP/1.1 302 Found`<br />`Location: https://my-redirect-uri.callback?code=js89p2x1`の場合、認可コードは`js89p21`です。                                                                                                                                   |
| `fragment`    | 暗黙付与のデフォルト値です。成功応答は`302 Found`で、`redirect_uri`（要求パラメーター）へのリダイレクトをトリガーします。応答パラメーターは、`Location`ヘッダー内にある`redirect_uri`のフラグメントコンポーネント（`#`に後続の部分）に埋め込まれます。<br />例：<br />`HTTP/1.1 302 Found`<br />`Location: https://my-redirect-uri/callback#access_token=eyB...78f&amp;token_type=Bearer&amp;expires_in=3600`                                                                                            |
| `form_post`   | 応答モードは、[OAuth 2.0 Form Post Response Mode specification](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html)の仕様に定義されています。成功応答は`200 OK`で、パラメーターはHTMLフォームに隠されたパラメーターとして埋め込まれます。フォームの`action`は`redirect_uri`で、フォームを送信するために`onload`属性が構成されます。ブラウザーがHTMLを読み込むと、`redirect_uri`にリダイレクトされます。                                                                                                  |
| `web_message` | この応答モードは、[OAuth 2.0 Web Message Response Mode specification](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00)の仕様に定義されています。/authorizationエンドポイントからの認可応答でリダイレクトするのではなく、HTML5 Webメッセージングが使用されます。これは、サイレント認証では特に便利です。この応答モードを使用するには、アプリのURLをAuth0の[アプリケーション設定](https://manage.auth0.com/#/applications/\{yourClientId}/settings)にある **［Allowed Web Origins（許可されているWebオリジン）］** フィールドで登録する必要があります。 |

### トークンエンドポイント

`/oauth/token`エンドポイントは、アプリケーションがアクセストークンやリフレッシュトークンを取得するのに使用されます。アクセストークンが直接発行される暗黙フローを除いて、すべてのフローで使用されます。

* 認可コードフローでは、アプリケーションは、認可エンドポイントから取得した認可コードをアクセストークンと交換します。
* クライアントの資格情報フローとリソース所有者のパスワード資格情報付与交換では、アプリケーションは資格情報のセットを使って認証し、アクセストークンを取得します。

## 状態パラメーター

認可プロトコルは`state`パラメーターを提供して、アプリケーションを以前の状態に復元できるようにします。`state`パラメーターは、クライアントが認可要求で設定した状態オブジェクトの一部を保持して、応答でクライアントが使用できるようにします。状態パラメーターを使用する主な理由は、CSRF攻撃を軽減するためです。詳細については「[OAuth 2.0の状態パラメーターを使用する](/docs/ja-jp/secure/attack-protection/state-parameters)」を参照してください。

## もっと詳しく

* [OAuth 2.0の状態パラメーターを使って攻撃を防ぎ、ユーザーをリダイレクトする](/docs/ja-jp/secure/attack-protection/state-parameters)
* [どちらのOAuth 2.0フローを使用するべきですか？](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)