> ## 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.

> アプリケーションと API の認証および認可で使用される各種フローについて説明します。

# 認証および認可フロー

Auth0 は、[OpenID Connect (OIDC) プロトコル](/ja/docs/authenticate/protocols/openid-connect-protocol) と [OAuth 2.0 認可フレームワーク](/ja/docs/authenticate/protocols/oauth) を使用して、ユーザーを認証し、保護されたリソースへのアクセスに必要な認可を取得します。Auth0 を使用すると、[認証と認可](/ja/docs/get-started/identity-fundamentals/authentication-and-authorization)に関する OIDC/<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を表示" href="/ja/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> の仕様やその他の技術的な詳細を意識することなく、独自のアプリケーションや API でさまざまなフローを簡単にサポートできます。

サーバーサイド、モバイル、デスクトップ、クライアントサイド、マシンツーマシン、デバイスアプリケーションの各シナリオに対応しています。

どのフローを使用すべきかわからない場合は、適切な選択をサポートします。詳しくは、[どの OAuth 2.0 フローを使用すべきですか？](/ja/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) を参照してください。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  複数のフローでは、実行中にアプリケーション自体も認可サーバーに対して認証する必要があります。アプリケーション認証の詳細については、[アプリケーション資格情報](/ja/docs/secure/application-credentials) を参照してください。
</Callout>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  API に設定したアプリケーションの API アクセスポリシーによっては、アプリケーションに対応するクライアントグラントを作成する必要がある場合があります。詳しくは、[API へのアプリケーションアクセス: ポリシーとクライアントグラント](/ja/docs/get-started/applications/application-access-to-apis-client-grants) を参照してください。
</Callout>

<div id="authorization-code-flow">
  ## Authorization Code Flow
</div>

一般的な Web アプリケーションは、ソースコードが公開されないサーバーサイドアプリケーションであるため、Authorization Code Flow を使用して Authorization Code をトークンに交換できます。

* [Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [Authorization Code Flow を使用してログインを追加](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [Authorization Code Flow を使用して API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow)

<div id="authorization-code-flow-with-proof-key-for-code-exchange-pkce">
  ## Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow
</div>

認証では、モバイルアプリケーションやネイティブアプリケーションでも Authorization Code Flow を使用できますが、追加のセキュリティ対策が必要です。さらに、シングルページアプリケーションには特有の課題があります。こうした課題を軽減するため、OAuth 2.0 では Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow が提供されています。

* [Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* [PKCE を使用する Authorization Code Flow にログインを追加する](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [PKCE を使用する Authorization Code Flow で API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce)

<div id="authorization-code-flow-with-enhanced-privacy-protection">
  ## プライバシー保護を強化した Authorization Code Flow
</div>

認証および認可のプロセスでは、[トランザクション認可](/ja/docs/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow) などのユースケースで、機密データを含む可能性があるコンテキスト情報がやり取りされることがあります。データや機密情報を保護するために、Authorization Code Flow では次のようなプロトコル拡張を利用できます。

* [Rich Authorization Requests (RAR) を使用した Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar)
* [Pushed Authorization Requests (PAR) を使用した Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par)
* [JWT-Secured Authorization Requests (JAR) を使用した Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar)
* [JSON Web Encryption (JWE)](/ja/docs/secure/tokens/access-tokens/json-web-encryption)

<div id="implicit-flow-with-form-post">
  ## Form Post を使用した Implicit Flow
</div>

OAuth 2.0 では、Authorization Code Flow の代替として、<Tooltip tip="Public Client: 認証情報を安全に保持できないクライアント（アプリケーション）。例として、ネイティブのデスクトップアプリケーションやモバイルアプリケーション、JavaScript ベースのクライアントサイド Web アプリケーション（シングルページアプリケーション（SPA）など）が含まれます。" cta="用語集を見る" href="/ja/docs/glossary?term=Public+Clients">パブリッククライアント</Tooltip>、または <Tooltip tip="Public Client: 認証情報を安全に保持できないクライアント（アプリケーション）。例として、ネイティブのデスクトップアプリケーションやモバイルアプリケーション、JavaScript ベースのクライアントサイド Web アプリケーション（シングルページアプリケーション（SPA）など）が含まれます。" cta="用語集を見る" href="/ja/docs/glossary?term=Client+Secrets">クライアントシークレット</Tooltip> を安全に保存できないアプリケーション向けに、Implicit Flow が提供されています。現在では、<Tooltip tip="Access Token: API にアクセスするために使用される、不透明な文字列または JWT 形式の認可クレデンシャル。" cta="用語集を見る" href="/ja/docs/glossary?term=Access+Tokens">アクセストークン</Tooltip> を要求する方法としてはベストプラクティスとは見なされていませんが、Form Post レスポンスモードと組み合わせることで、アプリケーションがユーザー認証のために <Tooltip tip="ID Token: リソースへのアクセスではなく、クライアント自体を対象としたクレデンシャル。" cta="用語集を見る" href="/ja/docs/glossary?term=ID+token">IDトークン</Tooltip> のみを必要とする場合には、よりシンプルなワークフローを実現できます。

* [Form Post を使用した Implicit Flow](/ja/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
* [Form Post を使用した Implicit Flow でログインを追加する](/ja/docs/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/add-login-using-the-implicit-flow-with-form-post)
* [Cookie を使用して SPA を認証する](/ja/docs/manage-users/cookies/spa-authenticate-with-cookies)

<div id="hybrid-flow">
  ## ハイブリッドフロー
</div>

クライアントシークレットを安全に保管できるアプリケーションでは、ハイブリッドフローを利用することでメリットが得られる場合があります。これは、Authorization Code Flow と Form Post を使用した Implicit Flow の機能を組み合わせたフローで、アプリケーションが IDトークン に即座にアクセスできる一方、アクセストークン と <Tooltip tip="リフレッシュトークン: ユーザーに再度ログインさせることなく、新しいアクセストークンを取得するために使用されるトークン。" cta="用語集を見る" href="/ja/docs/glossary?term=refresh+tokens">リフレッシュトークン</Tooltip> も安全かつ確実に取得できます。これは、アプリケーションがユーザーに関する情報にすぐアクセスする必要があるものの、保護されたリソースへ長期間アクセスする前に何らかの処理を行う必要がある場合に役立ちます。

* [ハイブリッドフロー](/ja/docs/get-started/authentication-and-authorization-flow/hybrid-flow)
* [ハイブリッドフローを使用して API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/hybrid-flow/call-api-hybrid-flow)

<div id="client-credentials-flow">
  ## クライアントクレデンシャルフロー
</div>

CLI、デーモン、バックエンドで実行されるサービスなどのマシン間 (M2M) アプリケーションでは、システムはユーザーではなくアプリケーション自体を認証し、認可します。このようなシナリオでは、識別子 + パスワードやソーシャルログインといった一般的な認証方式は適していません。代わりに、M2M アプリケーションではクライアントクレデンシャルフロー (OAuth 2.0 RFC 6749 のセクション 4.4 で定義) を使用します。

* [クライアントクレデンシャルフロー](/ja/docs/get-started/authentication-and-authorization-flow/client-credentials-flow)
* [クライアントクレデンシャルフローを使用して API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow)

<div id="device-authorization-flow">
  ## デバイス認可フロー
</div>

インターネットに接続する入力手段が限られたデバイスでは、ユーザーを直接認証する代わりに、ユーザーにコンピューターまたはスマートフォンでリンクを開き、デバイスを認可してもらいます。これにより、文字を簡単に入力できないデバイスでも、操作性の低下を避けられます。そのため、デバイスアプリでは Device <Tooltip tip="認可フロー: OAuth 2.0 フレームワークで規定される認可グラント（またはワークフロー）。" cta="用語集を表示" href="/ja/docs/glossary?term=Authorization+Flow">認可フロー</Tooltip> (OAuth 2.0 で策定) を使用します。モバイル/ネイティブアプリケーションで使用します。

* [デバイス認可フロー](/ja/docs/get-started/authentication-and-authorization-flow/device-authorization-flow)
* [デバイス認可フローを使用して API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/device-authorization-flow/call-your-api-using-the-device-authorization-flow)

<div id="resource-owner-password-flow">
  ## リソースオーナー パスワードフロー
</div>

推奨はしていませんが、高い信頼性が求められるアプリケーションでは、通常はインタラクティブなフォームを使用してユーザーに認証情報 (識別子とパスワード) の入力を求める <Tooltip tip="リソースオーナー: 保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。" cta="用語集を表示" href="/ja/docs/glossary?term=Resource+Owner">リソースオーナー</Tooltip> パスワードフローを使用できます。リソースオーナー パスワードフローは、リダイレクトベースのフロー ([Authorization Code Flow](/ja/docs/get-started/authentication-and-authorization-flow/authorization-code-flow) など) を使用できない場合にのみ使用してください。

* [リソースオーナー パスワードフロー](/ja/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [リソースオーナー パスワードフローを使用して API を呼び出す](/ja/docs/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)

<div id="client-initiated-backchannel-authentication-flow">
  ## クライアント主導バックチャネル認証フロー
</div>

クライアント主導バックチャネル認証フロー (CIBA) では、ユーザーを直接認証する代わりに、クライアントアプリケーションのバックエンドが認証フローを開始し、ユーザーに認証を求めます。実際の認証は、別の認証デバイス (通常はカスタムアプリが動作するスマートフォン) で行われます。

* [クライアント主導バックチャネル認証フロー](/ja/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow)
* [CIBA によるユーザー認証](/ja/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba)
* [CIBA によるユーザー認可](/ja/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authorization-with-ciba)

<div id="custom-token-exchange">
  ## Custom Token Exchange
</div>

Custom Token Exchange (CTE) を使用すると、[RFC 8693](https://datatracker.ietf.org/doc/html/rfc8693) で定義されている `/oauth/token` エンドポイントを呼び出し、既存の ID トークンを Auth0 トークンに交換できます。たとえば、Custom Token Exchange を使用して、ユーザーに代わって別のオーディエンスにアクセスするための Auth0 トークンに交換できます。Custom Token Exchange のユースケースの詳細については、[Example Use Cases](/ja/docs/authenticate/custom-token-exchange/cte-example-use-cases) を参照してください。

カスタム ロジックを含む Action に [Custom Token Exchange Profile](/ja/docs/authenticate/custom-token-exchange/configure-custom-token-exchange) を関連付けることで、認可ロジックを維持したまま、1 つのセキュリティ トークンを別のトークンに交換する、柔軟にカスタマイズされた ID ワークフローを実装できます。