認証および認可フロー

アプリケーションと API の認証および認可に使用されるさまざまなフローについて説明します。

Auth0 は、OpenID Connect (OIDC) Protocol と OAuth 2.0 Authorization Framework を使用して、ユーザーを認証し、保護されたリソースへのアクセスに必要な認可を取得します。Auth0 を使えば、OIDC/OAuth 2.0 の仕様や、認証と認可 に関するその他の技術的な詳細を意識することなく、独自のアプリケーションや API でさまざまなフローを簡単にサポートできます。

サーバーサイド、モバイル、デスクトップ、クライアントサイド、machine-to-machine、デバイス向けアプリケーションの各シナリオに対応しています。

どのフローを使用すべきかわからない場合は、適切な選択をお手伝いします。詳しくは、Which OAuth 2.0 Flow Should I Use? をお読みください。

いくつかのフローでは、実行中にアプリケーションも認可サーバーに対して認証を行う必要があります。アプリケーション認証の詳細については、Application Credentials をお読みください。

API に設定するアプリケーションの API アクセスポリシーによっては、アプリケーションに対応するクライアントグラントを作成する必要がある場合があります。詳しくは、Application Access to APIs: Policies and Client Grants をお読みください。

​

認可コードフロー

Regular Web Apps は、ソースコードが公開されないサーバーサイドのアプリケーションであるため、認可コードをトークンと交換する認可コードフローを利用できます。

• 認可コードフロー
• 認可コードフローで Login を追加
• 認可コードフローで API を呼び出す

​

PKCE を使用した Authorization Code フロー

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

• PKCE を使用した Authorization Code フロー
• PKCE を使用した Authorization Code フローで Login を追加する
• PKCE を使用した Authorization Code フローで API を呼び出す

​

プライバシー保護を強化した認可コードフロー

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

• Rich Authorization Requests (RAR) に対応した認可コードフロー
• プッシュ型認可リクエスト (PAR) に対応した認可コードフロー
• JWT で保護された認可リクエスト (JAR) に対応した認可コードフロー
• JSON Web Encryption (JWE)

​

Form Post を使用する Implicit Flow

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

• Form Post を使用する Implicit Flow
• Add Login Using the Form Post を使用する Implicit Flow
• Cookie を使用して SPA を認証する

​

ハイブリッドフロー

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

• ハイブリッドフロー
• ハイブリッドフローを使用して API を呼び出す

​

クライアント認証情報フロー

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

• クライアント認証情報フロー
• クライアント認証情報フローを使用して API を呼び出す

​

デバイス認可フロー

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

• デバイス認可フロー
• デバイス認可フローを使用して API を呼び出す

​

リソース所有者パスワードフロー

推奨はしていませんが、高信頼アプリケーションでは、通常は対話型フォームを使ってユーザーに資格情報 (識別子とパスワード) の入力を求めるリソース所有者パスワードフローを使用できます。リソース所有者パスワードフローは、リダイレクトベースのフロー (認可コードフロー など) を利用できない場合にのみ使用してください。

• リソース所有者パスワードフロー
• リソース所有者パスワードフローを使用して API を呼び出す

​

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

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

• クライアント主導のバックチャネル認証フロー
• CIBA によるユーザー認証
• CIBA によるユーザー認可

​

カスタムトークン交換

カスタムトークン交換 (CTE) を使用すると、RFC 8693 で定義されている /oauth/token エンドポイントを呼び出して、アプリケーションで既存のアイデンティティトークンを Auth0 トークンに交換できます。たとえば、カスタムトークン交換を使用すると、ユーザーに代わって別の audience にアクセスするために、Auth0 トークンを交換できます。カスタムトークン交換のユースケースについて詳しくは、使用例 を参照してください。

カスタムロジックを含む Action に Custom Token Exchange Profile を関連付けることで、認可ロジックを制御しながら、あるセキュリティトークンを別のトークンに交換し、高度にカスタマイズされたアイデンティティワークフローを実装できます。