Skip to main content
Auth0 は、OpenID Connect (OIDC) Protocol と OAuth 2.0 Authorization Framework を使用して、ユーザーを認証し、保護されたリソースへのアクセスに必要な認可を取得します。Auth0 を使えば、OIDC/ の仕様や、認証と認可 に関するその他の技術的な詳細を意識することなく、独自のアプリケーションや 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 は、ソースコードが公開されないサーバーサイドのアプリケーションであるため、認可コードをトークンと交換する認可コードフローを利用できます。

​
PKCE を使用した Authorization Code フロー

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

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

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

​
Form Post を使用する Implicit Flow

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

​
ハイブリッドフロー

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

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

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

​
デバイス認可フロー

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

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

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

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

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

​
カスタムトークン交換

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