OAuth 2.0 Authorization Framework は、複数の異なるフロー (またはグラント) をサポートしています。フロー アクセストークン アプリケーションタイプ によって決まりますが、クライアントの信頼レベルや、ユーザーにどのような体験を提供したいかといった他の要素も関係します。
Resource Owner クライアント : Resource Owner に代わって保護されたリソースへのアクセスを要求するアプリケーション。Resource Server 認可サーバー User Agent : Resource Owner がクライアントとやり取りするために使用するエージェント (ブラウザーやネイティブアプリケーションなど) 。
最初に判断すべきなのは、リソースへのアクセスを必要とする主体がマシンかどうかです。マシン間認可では、クライアントはリソースオーナーでもあるため、エンドユーザーによる認可は必要ありません。たとえば、API を使用して情報をデータベースにインポートする cron ジョブがこれに該当します。この例では、cron ジョブがクライアントであり、クライアントID クライアントシークレット
このケースが要件に合っている場合は、このフローの仕組みと実装方法について Client Credentials Flow を参照してください。
クライアントはサーバー上で実行されるウェブアプリですか？ クライアントがサーバー上で実行される通常のウェブアプリである場合は、Authorization Code Flow を使用してください。このフローを使用すると、クライアントはアクセストークンと、必要に応じて リフレッシュトークン
このケースが要件に合っている場合は、このフローの仕組みと実装方法について Authorization Code Flow を参照してください。
クライアントは、ユーザーの認証情報を任せられるほど十分に信頼できますか？ この判断ポイントでは、Resource Owner Password Credentials Grant を選択することがあります。このフローでは、通常はインタラクティブなフォームを使用して、エンドユーザーに認証情報 (識別子/パスワード) を入力してもらいます。この情報はバックエンドに送信され、そこから Auth0 に送られます。したがって、この情報をクライアントに安心して預けられることが絶対条件です。
このグラントは、リダイレクトベースのフロー (Authorization Code Flow など) が利用できない場合にのみ使用してください。これに該当する場合は、このフローの仕組みと実装方法について、Resource Owner Password Flow を参照してください。
クライアントがシングルページアプリ (SPA) (JavaScript などのスクリプト言語を使ってブラウザー上で実行されるアプリケーション) の場合、利用できるグラントは 2 つあります。Authorization Code Flow with Proof Key for Code Exchange (PKCE) と、Implicit Flow with Form Post です。ほとんどのケースでは、アクセストークンがクライアント側に公開されず、このフローでは リフレッシュトークン も返せるため、Authorization Code Flow with PKCE の使用を推奨します。
このフローの仕組みと実装方法の詳細については、Authorization Code Flow with Proof Key for Code Exchange (PKCE) を参照してください。Auth0 Single-Page App SDK は、SPA で Authorization Code Flow with PKCE を実装するための高レベル API を提供しています。
SPA でアクセストークンが不要な場合は、Implicit Flow with Form Post を使用できます。このフローの仕組みと実装方法の詳細については、Implicit Flow with Form Post を参照してください。
アプリケーションがネイティブアプリの場合は、Authorization Code Flow with Proof Key for Code Exchange (PKCE) を使用してください。
このフローの仕組みや実装方法の詳細については、Authorization Code Flow with Proof Key for Code Exchange (PKCE) を参照してください。
異なるリソースサーバーと通信する必要があるアプリケーションがある場合 1 つのアプリケーションが複数のリソースサーバー向けのアクセストークンを必要とする場合は、/authorize を複数回呼び出す必要があります (つまり、同じまたは異なる 認可フロー audience に異なる値を使用するため、フローの最後に取得されるアクセストークンも異なります。詳細については、OAuth 2.0: Audience Information Specification を参照してください。
アプリケーションを実装する前にエンドポイントを試せますか？ もちろんです。Authentication API Debugger Extension を使用できます。/grant エンドポイントごとの詳しい手順は、Authentication API Reference で確認できます。
Authorize エンドポイントについては、Authorize Application に移動し、テストするグラントに対応する「Test this endpoint」の段落を参照してください。
トークンエンドポイント Get Token に移動し、テストするグラントに対応する「Test this endpoint」セクションを参照してください。
クライアントアプリケーションで、ブラウザーを使わずにユーザーに認証を求める必要がありますか？
Client-Initiated Backchannel Authentication は現在 Early Access で提供されています。CIBA を有効にするには、担当の Technical Account Manager にお問い合わせください。
Client-Initiated Backchannel Authentication (CIBA) は、OpenID Connect とは別の認証フローを実装するための OpenID
クライアントアプリケーションが、エンドユーザーに代わって認証プロセスを開始します。
ユーザーとのやり取りにブラウザーは不要です。
クライアントアプリケーションと OpenID Provider の間で直接通信が行われます。
CIBA は、ユーザーがクライアントアプリケーションを信頼できない場合、クライアントアプリケーションにブラウザーがない場合、または認証が必要なアプリケーションの前にユーザーがいない場合に役立ちます。CIBA フローは、たとえば次のような場面で使用できます。
小売店の販売端末でのユーザーチェックイン: 店頭受け取りのシナリオでは、ユーザーは公共のキオスク端末で認証し、その場にいることを確認できます。コールセンターや窓口での認証: コールセンターの担当者は、通常はスマートフォン上のカスタムモバイルアプリを使用して、発信者を認証するための認証フローを開始できます。入力手段のないデバイスでの認証: たとえば、スマートスピーカー (またはその他の接続デバイス) は、通常はスマートフォン上のカスタムモバイルアプリを使用して、バックエンドサービス経由でユーザーに認証を求めることができます。
CIBA では 2 種類のデバイスを定義しています。
Consumption device : ユーザーがサービスを利用するためのデバイスです。Authentication device : ユーザーが認証を行い、同意を与えるデバイスです。
詳細については、Client-Initiated Backchannel Authentication Flow を参照してください。 
認証
ユーザー管理
カスタマイズ
Auth0 AI
プラットフォーム