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

OAuth 2.0の認可フレームワークは、複数の異なるフロー（または付与）をサポートしています。 フローはアクセストークンを取得する方法です。ユースケースに合ったものがどれかを判断する場合、主にアプリケーションタイプに左右されますが、クライアントへの信頼度やユーザーに届けたいエクスペリエンスといった、他の要因も重要になります。

• Resource Owner（リソース所有者）：保護されたリソースへのアクセス権を付与できるエンティティ。大抵の場合、エンドユーザーです。

• Client （クライアント）：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。

• Resource Server（リソースサーバー）：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。

• Authorization Server（認可サーバー）：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この例では、Auth0です。

• User Agent（ユーザーエージェント）：リソース所有者がクライアント（ブラウザーやネイティブアプリケーションなど）を操作するのに使用するエージェント。

最初の判断のポイントは、リソースにアクセスが必要な関係者がマシンかどうかです。マシンツーマシンの認可の場合、クライアントもリソース所有者であるため、エンドユーザーの認可は必要ありません。たとえば、APIを使用して情報をデータベースにインポートするcronジョブです。この例では、cronジョブはクライアントであり、リソース所有者です。その理由は、クライアントがクライアントIDとクライアントシークレットを持っていて、認可サーバーからアクセストークンを取得するのにそれらを使用しているからです。

これに該当するのであれば、このフローの仕組みと実装方法については、「クライアントの資格情報フロー」を参照してください。

クライアントがサーバー上で実行されている一般的なWebアプリであれば、認可コードフローが適しています。このフローを使用すれば、クライアントはアクセストークンを取得できる上に、リフレッシュトークンも任意で取得できます。アクセストークンはクライアントをホストしているWebサーバーへ直接渡されるため、最も安全な選択だと考えられています。ユーザーのWebブラウザーが関わることはなく、暴露のリスクもありません。

これに該当するのであれば、このフローの仕組みと実装方法については、「認可コードフロー」を参照してください。

決定のポイントは、リソース所有者のパスワード資格情報付与の処理結果になります。このフローでは、エンドユーザーは資格情報（識別子とパスワード）を、通常は対話型フォームを使用して提供するように要求されます。この情報はバックエンドに送信され、そこからAuth0へ送信されます。このため、この情報を扱うのにクライアントが絶対的に信頼できることが不可欠です。

この付与の使用は、（認可コードフローのような）リダイレクトベースのフローが使用できない場合にのみ限定すべきです。これに該当するのであれば、このフローの仕組みと実装方法については、「リソース所有者のパスワードフロー」を参照してください。

クライアントがシングルページアプリ（SPA）であれば、JavaScriptなどのスクリプト言語を使用してブラウザーで実行されているアプリケーションであることになり、付与には2つのオプションがあります。Proof Key for Code Exchange（PKCE）を使った認可コードフロー、そして、フォームPOSTを使った暗黙フローです。ほとんどの場合、PKCEを使った認可コードフローの使用をお勧めします。アクセストークンがクライアント側で暴露されることがない上に、このフローがリフレッシュトークンを返すことができます。

このフローの仕組みと実装方法については、「Proof Key for Code Exchange（PKCE）を使った認可コードフロー」を参照してください。Auth0のシングルページアプリSDKは、シングルページアプリでPKCEを使った認可コードフローを実装するのに、高水準のAPIを提供します。

SPAにアクセストークンが必要ないのであれば、フォームPOSTを使った暗黙フローを使用することができます。このフローの仕組みと実装方法については、「フォームPOSTを使った暗黙フロー」を参照してください。

アプリケーションがネイティブアプリの場合は、Proof Key for Code Exchange（PKCE）を使った認可コードフローを使用してください。

このフローの仕組みと実装方法については、「Proof Key for Code Exchange（PKCE）を使った認可コードフロー」を参照してください。

1つのアプリケーションが異なるリソースサーバーのアクセストークンを必要とする場合は、/authorizeを複数回呼び出す（つまり、同じまたは異なる認可フローの複数回実行）必要があります。それぞれの認可では異なるaudience値が使用されるため、フローの最後に生成されるアクセストークンも異なります。詳細については、「OAuth 2.0:Audience Information」の仕様を参照してください。

もちろんです！Authentication APIのデバッグ拡張機能を使用することができます。/grantエンドポイントについての詳しい指示は、「Authentication APIリファレンス」に記載されています。

• 認可エンドポイントについては、「アプリケーションを認可する」に記載の「このエンドポイントをテストする」段落をお読みください。

• トークンエンドポイントについては、「トークンを取得する」に記載の「このエンドポイントをテストする」段落をお読みください。

クライアントが開始するバックチャネル認証フロー（CIBA）は、OpenID Connectに対する代替の認証フローを実装するOpenID Foundationの標準です。CIBAは次の点で標準のOpenID Connectフローと異なります。

• クライアントアプリケーションがエンドユーザーに代わって認証プロセスを開始する。

• ブラウザーにユーザーインタラクションが不要である。

• クライアントアプリケーションとOpenIDプロバイダーが直接通信する。

CIBAは、ユーザーがクライアントアプリケーションを信頼できない、クライアントアプリケーションにブラウザーがない、またはユーザーが認証を必要とするアプリケーションの前にいない際に役立ちます。以下でCIBAフローが使用できる例をご紹介します。

• 販売端末でのユーザーのチェックイン：クリック＆コレクトのシナリオで、ユーザーは公共のキオスクで認証し、存在を確認できます。

• コールセンターまたは担当者デスクでの認証：コールセンターののオペレーターは認証フローを開始し、 発信者を認証できます。通常、スマートフォンのカスタムモバイルアプリを使用します。

• 入力なしでデバイスでの認証：たとえば、スマートスピーカー（または接続された別のデバイス）はバックエンドサービスを利用して、ユーザーにコンタクトし認証できます。通常、スマートフォンのカスタムモバイルアプリを使用します。

CIBAにより2つのデバイスが定義されます。

• 消費デバイス：ユーザーがサービスを使用できるようにするデバイス。

• 認証デバイス：ユーザーが認証、同意の付与を行うデバイス。

詳細については、「クライアントが開始するバックチャネル認証フロー」をお読みください。