OAuth 2.0の認可フレームワーク は、複数の異なるフロー（または付与）をサポートしています。 フロー アプリケーションタイプ に左右されますが、クライアントへの信頼度やユーザーに届けたいエクスペリエンスといった、他の要因も重要になります。
Resource Owner Client （クライアント） ：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。Resource Server Authorization Server User Agent（ユーザーエージェント） ：リソース所有者がクライアント（ブラウザーやネイティブアプリケーションなど）を操作するのに使用するエージェント。
最初の判断のポイントは、リソースにアクセスが必要な関係者がマシンかどうかです。マシンツーマシンの認可の場合、クライアントもリソース所有者であるため、エンドユーザーの認可は必要ありません。たとえば、APIを使用して情報をデータベースにインポートするcronジョブです。この例では、cronジョブはクライアントであり、リソース所有者です。その理由は、クライアントがクライアントIDとクライアントシークレットを持っていて、認可サーバーからアクセストークンを取得するのにそれらを使用しているからです。
これに該当するのであれば、このフローの仕組みと実装方法については、「クライアントの資格情報フロー 」を参照してください。
クライアントは、サーバー上で実行されているWebアプリですか？ クライアントがサーバー上で実行されている一般的な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を有効化するには、テクニカルアカウントマネージャーまでお問い合わせください。
クライアントが開始するバックチャネル認証フロー（CIBA）は、OpenID Connect に対する代替の認証フローを実装するOpenID
クライアントアプリケーションがエンドユーザーに代わって認証プロセスを開始する。
ブラウザーにユーザーインタラクションが不要である。
クライアントアプリケーションとOpenIDプロバイダーが直接通信する。
CIBAは、ユーザーがクライアントアプリケーションを信頼できない、クライアントアプリケーションにブラウザーがない、またはユーザーが認証を必要とするアプリケーションの前にいない際に役立ちます。以下でCIBAフローが使用できる例をご紹介します。
販売端末でのユーザーのチェックイン： クリック＆コレクトのシナリオで、ユーザーは公共のキオスクで認証し、存在を確認できます。コールセンターまたは担当者デスクでの認証： コールセンターののオペレーターは認証フローを開始し、 発信者を認証できます。通常、スマートフォンのカスタムモバイルアプリを使用します。入力なしでデバイスでの認証： たとえば、スマートスピーカー（または接続された別のデバイス）はバックエンドサービスを利用して、ユーザーにコンタクトし認証できます。通常、スマートフォンのカスタムモバイルアプリを使用します。
CIBAにより2つのデバイスが定義されます。
消費デバイス ：ユーザーがサービスを使用できるようにするデバイス。認証デバイス ：ユーザーが認証、同意の付与を行うデバイス。
詳細については、「クライアントが開始するバックチャネル認証フロー 」をお読みください。 
