メインコンテンツへスキップ
Auth0 は、OpenID Connect (OIDC) プロトコル と OAuth 2.0 認可フレームワーク を使用して、ユーザーを認証し、保護されたリソースへのアクセスに必要な認可を取得します。Auth0 を使用すると、認証と認可に関する OIDC/ の仕様やその他の技術的な詳細を意識することなく、独自のアプリケーションや API でさまざまなフローを簡単にサポートできます。 サーバーサイド、モバイル、デスクトップ、クライアントサイド、マシンツーマシン、デバイスアプリケーションの各シナリオに対応しています。 どのフローを使用すべきかわからない場合は、適切な選択をサポートします。詳しくは、どの OAuth 2.0 フローを使用すべきですか？ を参照してください。
複数のフローでは、実行中にアプリケーション自体も認可サーバーに対して認証する必要があります。アプリケーション認証の詳細については、アプリケーション資格情報 を参照してください。
API に設定したアプリケーションの API アクセスポリシーによっては、アプリケーションに対応するクライアントグラントを作成する必要がある場合があります。詳しくは、API へのアプリケーションアクセス: ポリシーとクライアントグラント を参照してください。

​
Authorization Code Flow

一般的な Web アプリケーションは、ソースコードが公開されないサーバーサイドアプリケーションであるため、Authorization Code Flow を使用して Authorization Code をトークンに交換できます。

​
Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow

認証では、モバイルアプリケーションやネイティブアプリケーションでも Authorization Code Flow を使用できますが、追加のセキュリティ対策が必要です。さらに、シングルページアプリケーションには特有の課題があります。こうした課題を軽減するため、OAuth 2.0 では Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow が提供されています。

​
プライバシー保護を強化した Authorization Code Flow

認証および認可のプロセスでは、トランザクション認可 などのユースケースで、機密データを含む可能性があるコンテキスト情報がやり取りされることがあります。データや機密情報を保護するために、Authorization Code Flow では次のようなプロトコル拡張を利用できます。

​
Form Post を使用した Implicit Flow

OAuth 2.0 では、Authorization Code Flow の代替として、、または を安全に保存できないアプリケーション向けに、Implicit Flow が提供されています。現在では、 を要求する方法としてはベストプラクティスとは見なされていませんが、Form Post レスポンスモードと組み合わせることで、アプリケーションがユーザー認証のために のみを必要とする場合には、よりシンプルなワークフローを実現できます。

​
ハイブリッドフロー

クライアントシークレットを安全に保管できるアプリケーションでは、ハイブリッドフローを利用することでメリットが得られる場合があります。これは、Authorization Code Flow と Form Post を使用した Implicit Flow の機能を組み合わせたフローで、アプリケーションが IDトークン に即座にアクセスできる一方、アクセストークン と も安全かつ確実に取得できます。これは、アプリケーションがユーザーに関する情報にすぐアクセスする必要があるものの、保護されたリソースへ長期間アクセスする前に何らかの処理を行う必要がある場合に役立ちます。

​
クライアントクレデンシャルフロー

CLI、デーモン、バックエンドで実行されるサービスなどのマシン間 (M2M) アプリケーションでは、システムはユーザーではなくアプリケーション自体を認証し、認可します。このようなシナリオでは、識別子 + パスワードやソーシャルログインといった一般的な認証方式は適していません。代わりに、M2M アプリケーションではクライアントクレデンシャルフロー (OAuth 2.0 RFC 6749 のセクション 4.4 で定義) を使用します。

​
デバイス認可フロー

インターネットに接続する入力手段が限られたデバイスでは、ユーザーを直接認証する代わりに、ユーザーにコンピューターまたはスマートフォンでリンクを開き、デバイスを認可してもらいます。これにより、文字を簡単に入力できないデバイスでも、操作性の低下を避けられます。そのため、デバイスアプリでは Device (OAuth 2.0 で策定) を使用します。モバイル/ネイティブアプリケーションで使用します。

​
リソースオーナー パスワードフロー

推奨はしていませんが、高い信頼性が求められるアプリケーションでは、通常はインタラクティブなフォームを使用してユーザーに認証情報 (識別子とパスワード) の入力を求める パスワードフローを使用できます。リソースオーナー パスワードフローは、リダイレクトベースのフロー (Authorization Code Flow など) を使用できない場合にのみ使用してください。

​
クライアント主導バックチャネル認証フロー

クライアント主導バックチャネル認証フロー (CIBA) では、ユーザーを直接認証する代わりに、クライアントアプリケーションのバックエンドが認証フローを開始し、ユーザーに認証を求めます。実際の認証は、別の認証デバイス (通常はカスタムアプリが動作するスマートフォン) で行われます。

​
Custom Token Exchange

Custom Token Exchange (CTE) を使用すると、RFC 8693 で定義されている /oauth/token エンドポイントを呼び出し、既存の ID トークンを Auth0 トークンに交換できます。たとえば、Custom Token Exchange を使用して、ユーザーに代わって別のオーディエンスにアクセスするための Auth0 トークンに交換できます。Custom Token Exchange のユースケースの詳細については、Example Use Cases を参照してください。 カスタム ロジックを含む Action に Custom Token Exchange Profile を関連付けることで、認可ロジックを維持したまま、1 つのセキュリティ トークンを別のトークンに交換する、柔軟にカスタマイズされた ID ワークフローを実装できます。