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

> サーバーサイドのWebアプリやSPAから、マシンツーマシンおよびデバイスフローまで、アプリケーションの種類に適したOAuth 2.0フローを見極める方法を学びます。

# どのOAuth 2.0フローを使用すべきですか？

[OAuth 2.0認可フレームワーク](/docs/ja-jp/authenticate/protocols/oauth)は、複数の異なるフロー (またはグラント) をサポートしています。<Tooltip tip="フロー: Actions を使用して拡張できるプロセス。各フローは1つ以上のトリガーで構成され、Auth0ジャーニーの単一の時点において情報が移動する論理パイプラインを表します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Flow">フロー</Tooltip>とは、<Tooltip tip="フロー: Actions を使用して拡張できるプロセス。各フローは1つ以上のトリガーで構成され、Auth0ジャーニーの単一の時点において情報が移動する論理パイプラインを表します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Access+Token">アクセストークン</Tooltip>を取得する方法です。どのフローがユースケースに適しているかは、主に[アプリケーションの種類](/docs/ja-jp/get-started/applications)によって決まりますが、クライアントの信頼レベルや、ユーザーにどのような体験を提供したいかといった、ほかの要素も関係します。

<div id="oauth-20-terminology">
  ## OAuth 2.0の用語
</div>

* **<Tooltip tip="リソース所有者: 保護されたリソースへのアクセスを許可できるエンティティ（ユーザーやアプリケーションなど）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Resource+Owner">リソース所有者</Tooltip>**: 保護されたリソースへのアクセスを許可できるエンティティ。通常はエンドユーザーを指します。
* **クライアント**: リソース所有者に代わって、保護されたリソースへのアクセスを要求するアプリケーション。
* **<Tooltip tip="リソースサーバー: 保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースへのリクエストを受け取り、それに応答します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Resource+Server">リソースサーバー</Tooltip>**: 保護されたリソースをホストするサーバー。アクセス先の API です。
* **<Tooltip tip="認可サーバー: ユーザーのアクセス範囲の境界を定義するうえで中心的な役割を果たすサーバー。たとえば、認可サーバーはユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Server">認可サーバー</Tooltip>**: リソース所有者を認証し、適切な認可を得たうえでアクセストークンを発行するサーバー。この場合は Auth0 です。
* **ユーザーエージェント**: リソース所有者がクライアントとやり取りするために使用するエージェント (たとえば、ブラウザーやネイティブアプリケーション) 。

<div id="is-the-client-the-resource-owner">
  ## クライアントはリソース所有者ですか？
</div>

最初の判断ポイントは、リソースへのアクセスを必要とする主体がマシンかどうかです。マシン間認可の場合、クライアントはリソース所有者でもあるため、エンドユーザーによる認可は必要ありません。たとえば、API を使用して情報をデータベースに取り込む cron ジョブがこれに当たります。この例では、cron ジョブは <Tooltip tip="Client ID: Auth0 から登録済みリソースに付与される識別子です。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=Client+ID">Client ID</Tooltip> と <Tooltip tip="Client Secret: クライアント（アプリケーション）が認可サーバーで認証を行うために使用する Secret です。これはクライアントと認可サーバーだけが知っている必要があり、推測されないよう十分にランダムでなければなりません。" cta="用語集を表示" href="/docs/ja-jp/glossary?term=Client+Secret">Client Secret</Tooltip> を保持し、それらを使って認可サーバーからアクセストークンを取得するため、クライアントであると同時にリソース所有者でもあります。

このケースが要件に合う場合は、このフローの仕組みと実装方法について [クライアント認証情報フロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow) を参照してください。

<div id="is-the-client-a-web-app-executing-on-the-server">
  ## クライアントはサーバー上で動作するウェブアプリですか？
</div>

クライアントがサーバー上で動作する従来型のウェブアプリである場合は、認可コードフローを使用します。このフローを使うと、クライアントはアクセストークンと、必要に応じて<Tooltip tip="リフレッシュトークン: ユーザーに再度ログインを求めることなく、新しいアクセストークンを取得するために使用するトークンです。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Refresh+Token">リフレッシュトークン</Tooltip>を取得できます。アクセストークンは、ユーザーのウェブブラウザーを経由せず、クライアントをホストしているウェブサーバーに直接渡されるため、漏えいのリスクが低く、最も安全な選択肢とされています。

このケースが要件に合っている場合は、このフローの仕組みと実装方法について、[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow)を参照してください。

<div id="is-the-client-absolutely-trusted-with-user-credentials">
  ## ユーザーの資格情報を託せるほど、クライアントは完全に信頼できますか？
</div>

この判断ポイントによっては、Resource Owner Password Credentials Grant を選ぶことになります。このフローでは通常、インタラクティブなフォームを使って、エンドユーザーに資格情報 (識別子/パスワード) を入力してもらいます。この情報はバックエンドに送信され、さらにそこから Auth0 に送られます。そのため、クライアントがこの情報を安心して任せられるほど信頼できることが不可欠です。

このグラントは、[認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow) のようなリダイレクトベースのフローが利用できない場合にのみ使用すべきです。これに当てはまる場合は、このフローの仕組みと実装方法について [Resource Owner Password Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/resource-owner-password-flow) を参照してください。

<div id="is-the-client-a-single-page-app">
  ## クライアントはシングルページアプリですか？
</div>

クライアントがシングルページアプリ (SPA)  (JavaScript のようなスクリプト言語を使ってブラウザー上で動作するアプリケーション) の場合、グラントには 2 つの選択肢があります。Proof Key for Code Exchange (PKCE) を使用した認可コードフローと、Form Post を使用する Implicit Flow です。ほとんどのケースでは、アクセストークンがクライアント側に公開されず、このフローでは[リフレッシュトークン](/docs/ja-jp/secure/tokens/refresh-tokens)も返せるため、PKCE を使用した認可コードフローの利用をお勧めします。

このフローの仕組みや実装方法について詳しくは、[Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)を参照してください。[Auth0 Single-Page App SDK](/docs/ja-jp/libraries/auth0-single-page-app-sdk) では、SPA で PKCE を使用した認可コードフローを実装するための高水準 API が提供されています。

SPA でアクセストークンが不要な場合は、Form Post を使用する Implicit Flow を利用できます。このフローの仕組みや実装方法について詳しくは、[Implicit Flow with Form Post](/docs/ja-jp/get-started/authentication-and-authorization-flow/implicit-flow-with-form-post)を参照してください。

<div id="is-the-client-a-nativemobile-app">
  ## クライアントはネイティブ／モバイルアプリですか？
</div>

アプリケーションがネイティブアプリの場合は、**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)を参照してください。

<div id="i-have-an-application-that-needs-to-talk-to-different-resource-servers">
  ## 異なるリソースサーバーと通信する必要があるアプリケーションがある場合
</div>

1 つのアプリケーションで異なるリソースサーバー向けのアクセストークンが必要な場合は、`/authorize` への呼び出しを複数回行う必要があります (つまり、同じまたは異なる <Tooltip tip="Authorization Flow: OAuth 2.0 フレームワークで指定される認可グラント（またはワークフロー）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Flow">認可フロー</Tooltip> を複数回実行する必要があります) 。各認可では `audience` に異なる値を使用するため、フローの最後にそれぞれ異なるアクセストークンが生成されます。詳しくは、[OAuth 2.0: Audience Information Specification](https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3) を参照してください。

<div id="can-i-try-the-endpoints-before-i-implement-my-application">
  ## アプリケーションを実装する前にエンドポイントを試すことはできますか？
</div>

もちろんです。[Authentication API Debugger Extension](/docs/ja-jp/customize/extensions/authentication-api-debugger-extension) を利用できます。各 `/grant` エンドポイントの詳しい手順は、[Authentication API Reference](https://auth0.com/docs/api/authentication) を参照してください。

* Authorize エンドポイントについては、[Authorize Application](https://auth0.com/docs/api/authentication#authorize-application) を開き、試したいグラントの「Test this endpoint」段落を読んでください。
* <Tooltip tip="トークンエンドポイント: プログラムからトークンをリクエストするために使用される、認可サーバー上のエンドポイント。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Token+endpoint">Token endpoint</Tooltip>については、[Get Token](https://auth0.com/docs/api/authentication#get-token) を開き、試したいグラントの「Test this endpoint」セクションを読んでください。

<div id="does-the-client-application-need-to-challenge-users-for-authentication-without-browser-interaction">
  ## クライアントアプリケーションは、ブラウザーを使った操作なしでユーザーに認証を求める必要がありますか？
</div>

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  クライアント主導のバックチャネル認証は現在、早期アクセスで提供されています。CIBA を有効にするには、担当の Technical Account Manager にお問い合わせください。
</Callout>

クライアント主導のバックチャネル認証 (CIBA) は、[OpenID Connect](https://openid.net/developers/how-connect-works/) とは異なる認証フローを実装するための <Tooltip tip="OpenID: ログイン情報を収集・保存することなく、アプリケーションがユーザーの本人確認を行えるようにする認証のオープン標準。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OpenID">OpenID</Tooltip> Foundation の標準です。CIBA が標準の OpenID Connect フローと異なる点は、次のとおりです。

* クライアントアプリケーションが、エンドユーザーに代わって認証プロセスを開始します。
* ユーザー操作にブラウザーは必要ありません。
* クライアントアプリケーションと OpenID プロバイダーの間で直接通信が行われます。

CIBA は、ユーザーがクライアントアプリケーションを信頼できない場合、クライアントアプリケーションにブラウザーがない場合、またはユーザーが認証を必要とするアプリケーションをその場で操作していない場合に役立ちます。CIBA フローを利用できる例をいくつか紹介します。

* **小売店の販売端末でのユーザーチェックイン:** クリック＆コレクトのシナリオでは、ユーザーは公共のキオスク端末で認証し、本人がその場にいることを確認できます。
* **コールセンターや窓口での認証:** コールセンターの担当者は、通常はスマートフォン上のカスタムモバイルアプリを使って、電話をかけてきたユーザーを認証するための認証フローを開始できます。
* **入力機能のないデバイスでの認証:** たとえば、スマートスピーカー (または他の接続デバイス) は、通常はスマートフォン上のカスタムモバイルアプリを使って、バックエンドサービス経由でユーザーに認証を求めることができます。

CIBA では 2 種類のデバイスを定義しています。

* **Consumption device**: ユーザーがサービスを利用するためのデバイスです。
* **Authentication device**: ユーザーが認証を行い、同意を与えるデバイスです。

詳しくは、[Client-Initiated Backchannel Authentication Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow) をご覧ください。