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

> ユースケースに適した OAuth 2.0 フローを見極める方法を学びます。

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

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

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

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

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

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

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

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

クライアントがサーバー上で実行される通常のウェブアプリである場合は、Authorization Code Flow を使用してください。このフローを使用すると、クライアントはアクセストークンと、必要に応じて <Tooltip tip="リフレッシュトークン: ユーザーに再度ログインを求めることなく、新しいアクセストークンを取得するために使用されるトークン。" cta="用語集を表示" href="/ja/docs/glossary?term=Refresh+Token">リフレッシュトークン</Tooltip> を取得できます。アクセストークンは、ユーザーのウェブブラウザーを経由して漏えいするリスクを負うことなく、クライアントをホストするウェブサーバーに直接渡されるため、これは最も安全な選択肢と考えられています。

このケースが要件に合っている場合は、このフローの仕組みと実装方法について [Authorization Code Flow](/ja/docs/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 に送られます。したがって、この情報をクライアントに安心して預けられることが絶対条件です。

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

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

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

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

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

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

アプリケーションがネイティブアプリの場合は、**Authorization Code Flow with Proof Key for Code Exchange (PKCE)** を使用してください。

このフローの仕組みや実装方法の詳細については、[Authorization Code Flow with Proof Key for Code Exchange (PKCE)](/ja/docs/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="/ja/docs/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](/ja/docs/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="/ja/docs/glossary?term=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">
  Client-Initiated Backchannel Authentication は現在 Early Access で提供されています。CIBA を有効にするには、担当の Technical Account Manager にお問い合わせください。
</Callout>

Client-Initiated Backchannel Authentication (CIBA) は、[OpenID Connect](https://openid.net/developers/how-connect-works/) とは別の認証フローを実装するための <Tooltip tip="OpenID: アプリケーションがログイン情報を収集および保存することなく、ユーザーの本人確認を行えるようにする認証のためのオープン標準です。" cta="用語集を表示" href="/ja/docs/glossary?term=OpenID">OpenID</Tooltip> Foundation の標準です。CIBA は、標準的な OpenID Connect フローと次の点で異なります。

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

CIBA は、ユーザーがクライアントアプリケーションを信頼できない場合、クライアントアプリケーションにブラウザーがない場合、または認証が必要なアプリケーションの前にユーザーがいない場合に役立ちます。CIBA フローは、たとえば次のような場面で使用できます。

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

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

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

詳細については、[Client-Initiated Backchannel Authentication Flow](/ja/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow) を参照してください。