複数のフローを実行するときは、アプリケーションも認可サーバーに対して認証を行う必要があります。アプリケーションの認証方法については、「アプリケーションの資格情報」をお読みください。
認可コードフロー
通常のWebアプリはソースコードが公開されないサーバー側アプリなので、認可コードとトークンを交換する認可コードフローを使用できます。Proof Key for Code Exchange（PKCE）を使った認可コードフロー
モバイルアプリケーションとネイティブアプリケーションは認証中に認可コードフローを使用できますが、追加のセキュリティ対策が必要です。加えて、シングルページアプリには特別な課題があります。これらのリスクを軽減するため、OAuth 2.0はProof Key for Code Exchange（PKCE）を活用した認可コードフローのバージョンを提供しています。プライバシー保護を強化した認可コードフロー
トランザクション認可のような一部のユースケースでは、認証と認可のプロセス中に、機密データを含む可能性のあるコンテキスト情報を交換します。このデータや機密情報を保護するため、認可コードフローには各種プロトコル改善策を使用できます。- Rich Authorization Requests（RAR）を使った認可コードフロー
- Pushed Authorization Requests（PAR）を使った認可コードフロー
- JWT-Secured Authorization Requests（JAR）を使った認可コードフロー
- PARとJARを使った認可コードフロー
- JSON Web Encryption（JWE）
フォームPOSTを使った暗黙フロー
OAuth 2.0では、認可コードフローの代わりとして、パブリッククライアントや、クライアントシークレットを安全に保存することのできないアプリケーションでの使用を意図した暗黙フローも提供しています。これは現在ではアクセストークンを要求するためのベストプラクティスとはみなされないフローですが、アプリケーションがユーザー認証にIDトークンのみを必要とする場合、フォームPOST応答モードと併用することでワークフローが効率化します。ハイブリッドフロー
クライアントシークレットを安全に保存できるアプリケーションには、ハイブリッドフローが有効です。これは認可コードフローと暗黙フローにフォームPOSTを組み合わせたフローで、アプリケーションはIDトークンに即座にアクセスできるとともに、アクセストークンとリフレッシュトークンを安全に取得できます。これは、アプリケーションがユーザー情報に対して即時アクセスを必要とする場合には便利ですが、何らかの処理を行わないと、保護されたリソースに長期間アクセスすることはできません。クライアントの資格情報フロー
バックエンドで動作するCLIやデーモン、サービスなどのマシンツーマシン（M2M）アプリケーションでは、システムがユーザーではなくアプリを認証および認可します。このシナリオでは、識別子とパスワードや、ソーシャルログインなどの典型的な認証方式では意味がありません。代わりに、M2Mアプリではクライアントの資格情報フローを使用します（OAuth 2.0 RFC 6749第4.4節に定義）。デバイス認可フロー
ユーザーを直接認証するのではなく、入力に制約のあるインターネット接続デバイスでは、コンピューターやスマートフォンのリンクをクリックして、デバイスを認可するようユーザーに求めます。そうすることで、テキストを入力するのに手軽な方法がないデバイスで、ユーザーエクスペリエンスの質が下がることを防ぎます。これを行うために、デバイスアプリではデバイス認可フローを使用します（OAuth 2.0でドラフト作成）。モバイル／ネイティブアプリケーションで使用します。Resource Owner Password（リソース所有者のパスワード）フロー
推奨はされませんが、信頼性の高いアプリケーションでは、リソース所有者のパスワードフローを使うことができます。このフローは、ユーザーに資格情報（識別子とパスワード）の提供を要求するもので、通常は対話型フォームを使用します。リソース所有者のパスワードフローの使用は、（認可コードフローのような）リダイレクトベースのフローが使用できない場合にのみ限定すべきです。クライアントが開始するバックチャネル認証フロー
現在、クライアントが開始するバックチャネル認証は早期アクセスで利用できます。CIBAを有効化するには、テクニカルアカウントマネージャーまでお問い合わせください。