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

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

どのフローを使用すべきかわからない場合は、適切な選択をお手伝いします。詳しくは、[Which OAuth 2.0 Flow Should I Use?](/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">
  いくつかのフローでは、実行中にアプリケーションも認可サーバーに対して認証を行う必要があります。アプリケーション認証の詳細については、[Application Credentials](/docs/ja-jp/secure/application-credentials) をお読みください。
</Callout>

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

<div id="authorization-code-flow">
  ## 認可コードフロー
</div>

Regular Web Apps は、ソースコードが公開されないサーバーサイドのアプリケーションであるため、認可コードをトークンと交換する認可コードフローを利用できます。

* [認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)
* [認可コードフローで Login を追加](/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)

<div id="authorization-code-flow-with-proof-key-for-code-exchange-pkce">
  ## PKCE を使用した Authorization Code フロー
</div>

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

* [PKCE を使用した Authorization Code フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)
* [PKCE を使用した Authorization Code フローで Login を追加する](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce/add-login-using-the-authorization-code-flow-with-pkce)
* [PKCE を使用した Authorization Code フローで 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)

<div id="authorization-code-flow-with-enhanced-privacy-protection">
  ## プライバシー保護を強化した認可コードフロー
</div>

認証および認可のプロセスでは、[トランザクションごとの認可](/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)
* [プッシュ型認可リクエスト (PAR) に対応した認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-par)
* [JWT で保護された認可リクエスト (JAR) に対応した認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/authorization-code-flow-with-jar)
* [JSON Web Encryption (JWE)](/docs/ja-jp/secure/tokens/access-tokens/json-web-encryption)

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

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

* [Form Post を使用する Implicit Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)
* [Add Login Using the Form Post を使用する Implicit Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post/add-login-using-the-implicit-flow-with-form-post)
* [Cookie を使用して SPA を認証する](/docs/ja-jp/manage-users/cookies/spa-authenticate-with-cookies)

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

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

* [ハイブリッドフロー](/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)

<div id="client-credentials-flow">
  ## クライアント認証情報フロー
</div>

CLI、デーモン、またはバックエンドで実行されるサービスのような machine-to-machine (M2M) アプリケーションでは、システムはユーザーではなくアプリケーションを認証して認可します。このようなケースでは、identifier + password やソーシャルログインといった一般的な認証方式は適していません。代わりに、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)

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

インターネットに接続する入力手段が限られたデバイスでは、ユーザーを直接認証する代わりに、ユーザーにコンピューターやスマートフォンでリンク先にアクセスしてデバイスを認可してもらいます。これにより、文字を簡単に入力できないデバイスでも、使いにくい操作を避けられます。これを実現するために、デバイス用アプリは Device <Tooltip tip="Authorization Flow: OAuth 2.0 フレームワークで規定された認可グラント（またはワークフロー）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Flow">認可フロー</Tooltip> (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)

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

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

* [リソース所有者パスワードフロー](/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)

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

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

<div id="custom-token-exchange">
  ## カスタムトークン交換
</div>

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

カスタムロジックを含む Action に [Custom Token Exchange Profile](/docs/ja-jp/authenticate/custom-token-exchange/configure-custom-token-exchange) を関連付けることで、認可ロジックを制御しながら、あるセキュリティトークンを別のトークンに交換し、高度にカスタマイズされたアイデンティティワークフローを実装できます。