> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

> Auth0によるOAuth 2.0認可フレームワークの実装について、サポートされているグラントタイプやAPIとアプリケーションを保護するための主要なエンドポイントを含めて学びます。

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

<Card title="Overview">
  主要概念

  * Auth0は、Internet Engineering Task Force (IETF) が策定したOAuth 2.0プロトコルをサポートしています。
  * OAuth 2.0仕様の役割、グラントタイプ (またはワークフロー) 、エンドポイントについて説明します。
</Card>

[OAuth 2.0](https://tools.ietf.org/html/rfc6749)認可フレームワークは、ユーザーが長期的な資格情報やアイデンティティを明かすことなく、サードパーティのウェブサイトやアプリケーションに保護されたリソースへのアクセスを許可できるプロトコルです。

<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth">
  OAuth
</Tooltip>

は認可レイヤーを導入し、クライアントの役割を

<Tooltip tip="リソース所有者: 保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=resource+owner">
  リソース所有者
</Tooltip>

の役割から切り離します。OAuthでは、クライアントはリソース所有者が管理し

<Tooltip tip="リソースサーバー: 保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースへのリクエストを受け付け、応答します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=resource+server">
  リソースサーバー
</Tooltip>

がホストするリソースへのアクセスを要求し、リソース所有者とは異なる資格情報が発行されます。保護されたリソースへのアクセスにリソース所有者の資格情報を使用する代わりに、クライアントは

<Tooltip tip="アクセストークン: APIへのアクセスに使用される、不透明な文字列またはJWT形式の認可クレデンシャル。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+token">
  アクセストークン
</Tooltip>

(特定のスコープ、有効期間、その他のアクセス属性を示す文字列) を取得します。アクセストークンは、リソース所有者の承認のもと、

<Tooltip tip="認可サーバー: ユーザーのアクセス範囲の定義に貢献する中央集権的なサーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=authorization+server">
  認可サーバー
</Tooltip>

によってサードパーティのクライアントに発行されます。その後、クライアントはそのアクセストークンを使用して、リソースサーバーがホストする保護されたリソースにアクセスします。

Auth0は、APIの認可シナリオ向けに[JSON Web Token (JWT) 形式](/docs/ja-jp/secure/tokens/json-web-tokens/json-web-token-structure)でアクセストークンを生成します。アクセストークンが表すpermissionsは、OAuthの用語では[スコープ](/docs/ja-jp/get-started/apis/scopes)と呼ばれます。アプリケーションがAuth0で認証する際に必要なスコープを指定し、ユーザーによってそれらのスコープが認可されると、アクセストークンはその認可済みスコープを表します。

<div id="roles">
  ## 役割
</div>

OAuth 2.0のフローには、次の役割があります。

* **リソース所有者**: 保護されたリソースへのアクセスを許可できる主体です。通常はエンドユーザーを指します。
* **リソースサーバー**: 保護されたリソースをホストするサーバーです。つまり、アクセスしたいAPIのことです。
* **クライアント**: リソース所有者に代わって、保護されたリソースへのアクセスを要求するアプリケーションです。
* **認可サーバー**: リソース所有者を認証し、適切な認可を得たうえでアクセストークンを発行するサーバーです。この場合はAuth0です。

<div id="grant-types">
  ## グラントタイプ
</div>

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

* [Authorization Code Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow): サーバー上で動作する Web アプリで使用されます。モバイルアプリでも、[Proof Key for Code Exchange (PKCE) technique](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) を使用して利用されます。
* [Implicit Flow with Form Post](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post): ユーザーのブラウザー上で動作する、JavaScript を中心としたアプリ (Single-Page Applications) で使用されます。
* [Resource Owner Password Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow): 高い信頼性を前提とするアプリで使用されます。
* [Client Credentials Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow): マシン間通信に使用されます。

この仕様では、追加のグラントタイプを定義するための拡張メカニズムも提供されています。各グラントタイプの仕組みや使用すべき場面について詳しくは、[Authentication and Authorization Flows](/docs/ja-jp/get-started/authentication-and-authorization-flow) を参照してください。

<div id="endpoints">
  ## エンドポイント
</div>

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

<div id="authorization-endpoint">
  ### 認可エンドポイント
</div>

`/authorize` エンドポイントは、リソース所有者とやり取りして、保護されたリソースにアクセスするための認可を取得するために使用されます。これを理解しやすくするために、Google アカウントを使ってサービスにログインする場面を想像してみてください。まず、サービスは認証のために Google にリダイレクトします (まだログインしていない場合) 。その後、同意画面が表示され、そのサービスに対して、メールアドレスや連絡先リストなど、あなたのデータ (保護されたリソース) の一部へのアクセスを許可するよう求められます。

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

| Parameter       | Description                                                                                                                                                                                                                                                                                                                   |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `response_type` | 認可サーバーに、どの grant を実行するかを伝えます。                                                                                                                                                                                                                                                                                                 |
| `response_mode` | (任意) 認可リクエストの結果をどの形式で返すかを指定します。値:<br />- `query`: Authorization Code grant 用。`302 Found` によってリダイレクトされます。<br />- `fragment`: Implicit grant 用。`302 Found` によってリダイレクトされます。<br />- `form_post`: レスポンスパラメータを hidden パラメータとして HTML form に埋め込んだ `200 OK`。<br />- `web_message`: Silent Authentication 用。HTML5 web messaging を使用します。 |
| `client_id`     | 認可を要求するアプリケーションの ID です。                                                                                                                                                                                                                                                                                                       |
| `redirect_uri`  | URL を指定します。このエンドポイントから正常なレスポンスが返されると、この URL にリダイレクトされます。                                                                                                                                                                                                                                                                      |
| `scope`         | アプリケーションが必要とする permissions をスペース区切りで並べた一覧です。                                                                                                                                                                                                                                                                                  |
| `state`         | セキュリティ目的で使用される不透明な値です。このリクエストパラメータが設定されている場合、`redirect_uri` の一部としてアプリケーションに返されます。                                                                                                                                                                                                                                             |
| `connection`    | Passwordless connections の接続タイプを指定します                                                                                                                                                                                                                                                                                         |

アプリケーションがユーザーを認証するために `/authorize` エンドポイントへ最初のリクエストを送る際に、カスタムクエリパラメータを設定できます。カスタムクエリパラメータを使用すると、<Tooltip tip="Universal Login: アプリケーションは、ユーザーの本人確認のために、Auth0 の Authorization Server でホストされている Universal Login にリダイレクトします。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Universal+Login">Universal Login</Tooltip> のページテンプレートに追加のコンテキストを渡せます。

`connection` パラメータを使用するには、ID First を有効にする必要があります。`connection` パラメータと Universal Login の詳細については、[Passwordless for Universal Login](/docs/ja-jp/authenticate/passwordless/passwordless-with-universal-login) を参照してください。

`ext-` で始まるクエリパラメータは、自動的に [page template context](/docs/ja-jp/customize/login-pages/universal-login/customize-templates#custom-query-parameters) に表示されます。

このエンドポイントは、Authorization Code グラントタイプ と Implicit グラントタイプ で使用されます。認可サーバーは、アプリケーションがどの グラントタイプ を使いたいかを把握する必要があります。これは、発行する credential の種類に影響するためです。

* Authorization Code grant の場合は、認可コードを発行します (これは後で `/oauth/token` エンドポイントでアクセストークンと交換できます) 。
* Implicit grant の場合は、アクセストークンを発行します。これは、誰がどのアプリケーションに対してどの permissions (scopes) を認可したかを示す不透明な文字列 (または Auth0 の実装では <Tooltip tip="JSON Web Token (JWT): 2 者間で claim を安全に表現するために使われる標準的な ID Token 形式（および多くの場合 Access Token 形式）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=JWT">JWT</Tooltip>) です。

どの グラントタイプ を使用するかを認可サーバーに伝えるために、`response_type` リクエストパラメータを次のように使用します。

* Authorization Code grant の場合は、認可コードを含めるために `response_type=code` を使用します。
* Implicit grant の場合は、アクセストークンを含めるために `response_type=token` を使用します。代わりに `response_type=id_token token` を使用して、アクセストークンと <Tooltip tip="ID Token: リソースへのアクセスではなく、client 自体のための credential。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=ID+token">ID token</Tooltip> の両方を含めることもできます。

ID token は、ログインしているユーザーに関する情報を含む JWT です。これは <Tooltip tip="OpenID: アプリケーションがログイン情報を収集・保存することなくユーザーの本人確認を行えるようにする authentication のためのオープン標準。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) で導入されました。

[OAuth 2.0 Multiple Response Type Encoding Practices specification](https://openid.net/specs/oauth-v2-multiple-response-types-1_0.html) では、認可リクエストの結果をどのような形式で返すかを指定するパラメータが追加されました。このパラメータは `response_mode` と呼ばれます。これは任意で、次の値を取ることができます:

| Value         | Description                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `query`       | これは Authorization Code grant のデフォルトです。成功したレスポンスは `302 Found` で、`redirect_uri` へのリダイレクトが発生します。レスポンスパラメーターは、`Location` ヘッダー内の `redirect_uri` の query コンポーネント (`?` の後の部分) に埋め込まれます。<br />例:<br />`HTTP/1.1 302 Found`<br />`Location: https://my-redirect-uri.callback?code=js89p2x1` この場合、authorization code は `js89p21` です。                                                                                                                                |
| `fragment`    | これは Implicit Grant のデフォルトです。成功したレスポンスは `302 Found` で、`redirect_uri` (リクエストパラメーター) へのリダイレクトが発生します。レスポンスパラメーターは、`Location` ヘッダー内の `redirect_uri` の fragment コンポーネント (`#` の後の部分) に埋め込まれます。<br />例:<br />`HTTP/1.1 302 Found`<br />`Location: https://my-redirect-uri/callback#access_token=eyB...78f&token_type=Bearer&expires_in=3600`.                                                                                                                     |
| `form_post`   | この response mode は [OAuth 2.0 Form Post Response Mode specification](https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html) で定義されています。成功したレスポンスは `200 OK` で、パラメーターは hidden params として HTML form に埋め込まれます。form の `action` は `redirect_uri` で、`onload` 属性は form を送信するように設定されます。HTML がブラウザーに読み込まれた後、`redirect_uri` へのリダイレクトが行われます。                                                                                                              |
| `web_message` | この response mode は [OAuth 2.0 Web Message Response Mode specification](https://tools.ietf.org/html/draft-sakimura-oauth-wmrm-00) で定義されています。/authorization endpoint からの authorization response では、リダイレクトの代わりに HTML5 Web Messaging を使用します。これは Silent Authentication を使用する場合に特に便利です。この response mode を使用するには、Auth0 の [アプリケーション設定](https://manage.auth0.com/#/applications/\{yourClientId}/settings) にある **Allowed Web Origins** フィールドにアプリの URL を登録する必要があります。 |

<div id="token-endpoint">
  ### トークンエンドポイント
</div>

`/oauth/token` エンドポイントは、アプリケーションがアクセストークンまたは <Tooltip tip="リフレッシュトークン: ユーザーに再度ログインを求めることなく、新しいアクセストークンを取得するために使用されるトークン。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=refresh+token">リフレッシュトークン</Tooltip> を取得するために使用されます。アクセストークンは直接発行されるため、Implicit Flow を除くすべてのフローで使用されます。

* Authorization Code Flow では、アプリケーションは認可エンドポイントから取得した認可コードをアクセストークンと交換します。
* Client Credentials Flow および Resource Owner Password Credentials Grant Exchange では、アプリケーションは一連の認証情報を使って認証を行い、その後アクセストークンを取得します。

<div id="state-parameters">
  ## State parameters
</div>

認可プロトコルでは、アプリケーションの前の状態を復元できるようにする `state` パラメーターが用意されています。`state` パラメーターは、クライアントが 認可リクエスト で設定した状態オブジェクトの一部を保持し、それをレスポンスでクライアントが利用できるようにします。`state` パラメーターを使用する主な目的は、CSRF 攻撃を軽減することです。詳細については、[Use OAuth 2.0 State Parameters](/docs/ja-jp/secure/attack-protection/state-parameters) を参照してください。

<div id="learn-more">
  ## 詳細はこちら
</div>

* [OAuth 2.0のState parametersを使って攻撃を防ぎ、ユーザーをリダイレクトする](/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)