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

# 認証フローと認可フロー

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

Auth0は[OpenID Connect（OIDC）プロトコル](/docs/ja-jp/authenticate/protocols/openid-connect-protocol)と[OAuth 2.0認可フレームワーク](/docs/ja-jp/authenticate/protocols/oauth)を使用して、ユーザーを認証し、保護されたリソースにアクセスするためのユーザーの認可を得ます。Auth0を使うと、OIDC/<Tooltip data-tooltip-id="react-containers-DefinitionTooltip-1" href="/docs/ja-jp/glossary?term=oath2" tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワーク。" cta="用語集の表示">OAuth 2.0</Tooltip>の仕様やその他の[認証・認可](/docs/ja-jp/get-started/identity-fundamentals/authentication-and-authorization)の技術的側面を気にすることなく、独自のアプリケーションとAPIで各種フローを簡単にサポートすることができます。

サーバー側、モバイル、デスクトップ、クライアント側、マシンツーマシン、およびデバイスアプリケーションのシナリオがサポートされています。

使うべきフローの選択でお困りの場合は、「[どのOAuth 2.0フローを使用するべきですか？](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use)」で詳細をお読みください。

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  複数のフローを実行するときは、アプリケーションも認可サーバーに対して認証を行う必要があります。アプリケーションの認証方法については、「[アプリケーションの資格情報](/docs/ja-jp/secure/application-credentials)」をお読みください。
</Callout>

## 認可コードフロー

通常のWebアプリはソースコードが公開されないサーバー側アプリなので、認可コードとトークンを交換する認可コードフローを使用できます。

* [認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [認可コードフローを使用してログインを追加する](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/add-login-auth-code-flow)
* [認可コードフローを使用してAPIを呼び出す](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow)

## Proof Key for Code Exchange（PKCE）を使った認可コードフロー

モバイルアプリケーションとネイティブアプリケーションは認証中に認可コードフローを使用できますが、追加のセキュリティ対策が必要です。加えて、シングルページアプリには特別な課題があります。これらのリスクを軽減するため、OAuth 2.0はProof Key for Code Exchange（PKCE）を活用した認可コードフローのバージョンを提供しています。

* [Proof Key for Code Exchange（PKCE）を使った認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* [PKCEを使った認可コードフローでログインを追加する](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [PKCEを使った認可コードフローでAPIを呼び出す](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/call-your-api-using-the-authorization-code-flow-with-pkce)

## プライバシー保護を強化した認可コードフロー

[トランザクション認可](/docs/ja-jp/secure/highly-regulated-identity/transactional-authorization-with-authorization-code-flow)のような一部のユースケースでは、認証と認可のプロセス中に、機密データを含む可能性のあるコンテキスト情報を交換します。このデータや機密情報を保護するため、認可コードフローには各種プロトコル改善策を使用できます。

* [Rich Authorization Requests（RAR）を使った認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-rar)
* [Pushed Authorization Requests（PAR）を使った認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par)
* [JWT-Secured Authorization Requests（JAR）を使った認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar)
* [PARとJARを使った認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par-and-jar)
* [JSON Web Encryption（JWE）](/docs/ja-jp/secure/tokens/access-tokens/json-web-encryption)

## フォームPOSTを使った暗黙フロー

OAuth 2.0では、認可コードフローの代わりとして、パブリッククライアントや、クライアントシークレットを安全に保存することのできないアプリケーションでの使用を意図した暗黙フローも提供しています。これは現在ではアクセストークンを要求するためのベストプラクティスとはみなされないフローですが、アプリケーションがユーザー認証にIDトークンのみを必要とする場合、フォームPOST応答モードと併用することでワークフローが効率化します。

* [フォームPOSTを使った暗黙フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
* [フォームPOSTを使った暗黙フローでログインを追加する](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/add-login-using-the-implicit-flow-with-form-post)
* [クッキーを使ってSPAを認証する](/docs/ja-jp/manage-users/cookies/spa-authenticate-with-cookies)

## ハイブリッドフロー

クライアントシークレットを安全に保存できるアプリケーションには、ハイブリッドフローが有効です。これは認可コードフローと暗黙フローにフォームPOSTを組み合わせたフローで、アプリケーションはIDトークンに即座にアクセスできるとともに、アクセストークンとリフレッシュトークンを安全に取得できます。これは、アプリケーションがユーザー情報に対して即時アクセスを必要とする場合には便利ですが、何らかの処理を行わないと、保護されたリソースに長期間アクセスすることはできません。

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

## クライアントの資格情報フロー

バックエンドで動作するCLIやデーモン、サービスなどのマシンツーマシン（M2M）アプリケーションでは、システムがユーザーではなくアプリを認証および認可します。このシナリオでは、識別子とパスワードや、ソーシャルログインなどの典型的な認証方式では意味がありません。代わりに、M2Mアプリではクライアントの資格情報フローを使用します（OAuth 2.0 RFC 6749第4.4節に定義）。

* [クライアントの資格情報フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow)
* [クライアントの資格情報フローを使用してAPIを呼び出す](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow/call-your-api-using-the-client-credentials-flow)

## デバイス認可フロー

ユーザーを直接認証するのではなく、入力に制約のあるインターネット接続デバイスでは、コンピューターやスマートフォンのリンクをクリックして、デバイスを認可するようユーザーに求めます。そうすることで、テキストを入力するのに手軽な方法がないデバイスで、ユーザーエクスペリエンスの質が下がることを防ぎます。これを行うために、デバイスアプリではデバイス認可フローを使用します（OAuth 2.0でドラフト作成）。モバイル／ネイティブアプリケーションで使用します。

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

## Resource Owner Password（リソース所有者のパスワード）フロー

推奨はされませんが、信頼性の高いアプリケーションでは、リソース所有者のパスワードフローを使うことができます。このフローは、ユーザーに資格情報（識別子とパスワード）の提供を要求するもので、通常は対話型フォームを使用します。リソース所有者のパスワードフローの使用は、（[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)のような）リダイレクトベースのフローが使用できない場合にのみ限定すべきです。

* [Resource Owner Password（リソース所有者のパスワード）フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow)
* [リソース所有者のパスワードフローを使ってAPIを呼び出す](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow/call-your-api-using-resource-owner-password-flow)

## クライアントが開始するバックチャネル認証フロー

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  現在、クライアントが開始するバックチャネル認証は早期アクセスで利用できます。CIBAを有効化するには、テクニカルアカウントマネージャーまでお問い合わせください。
</Callout>

クライアントが開始するバックチャネル認証フロー（CIBA）を使用すると、ユーザーを直接認証するのではなく、クライアントアプリケーションのバックエンドで認証フローが開始され、ユーザーをチャレンジして認証します。認証自体は、別の認証デバイス（通常、カスタムアプリを実行するスマートフォン）で実行されます。

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