このチュートリアルでは、リソース所有者のパスワードフローを使用して独自のAPIを呼び出します。フローの仕組みやメリットについては、「リソース所有者のパスワードフロー」を参照してください。
リソース所有者のパスワード（ROP）フローには、ユーザーのパスワードを処理するアプリケーションが関与するため、サードパーティクライアントで使用してはなりません。
前提条件
このチュートリアルを始める前に：-
Auth0にアプリケーションを登録します。
- ［Regular Web Apps（通常のWebアプリ）］ の ［Application Type（アプリケーションタイプ）］ を選択します。
{https://yourApp/callback}の ［Allowed Callback（許可されているコールバック）］URL を追加します。このフィールドを未定義にすることはできません。未定義にすると、エラーメッセージが返されます。- アプリケーションの ［Grant Types（付与タイプ）］ に ［Password（パスワード）］ が含まれていることを確認します。詳細については、「付与タイプを更新する」をお読みください。
- アプリケーションでリフレッシュトークンを使用できるようにするには、アプリケーションの ［Grant Types（付与タイプ）］ に ［Refresh Token（リフレッシュトークン）］ が含まれていることを確認してください。詳細については、「付与タイプを更新する」をお読みください。リフレッシュトークンの詳細については、「リフレッシュトークン」をお読みください。
-
APIをAuth0に登録する
- APIがリフレッシュトークンを受信して、以前のトークンの有効期限が切れたときに新しいトークンを取得できるようにする場合は、［Allow Offline Access（オフラインアクセスの許可）］ を有効にします。
-
Set up a connection（接続のセットアップ）
- ユーザー名とパスワードによるユーザー認証が可能な接続であることを確認します（例：データベース接続、またはAD/LDAP、ADFS、Entra IDエンタープライズ接続)。
-
特定の接続にのみ影響を与えるように、ルールを更新または無効化します。リソース所有者のパスワー付与をテストしている際に
access_deniedエラーが発生した場合、アクセス制御ルールが原因である可能性があります。
ステップ
- テナントを構成する：テナントのデフォルト接続を設定します。
- トークンを要求する： 認可コードをトークンと交換します。
- APIを呼び出す： 取得したアクセストークンを使ってAPIを呼び出します。
- リフレッシュトークン： 既存のトークンが期限切れになったら、リフレッシュトークンを使用して新しいトークンを要求します。
テナントを構成する
リソース所有者のパスワードフローは、ユーザー名とパスワードでユーザーを認証できる接続に依存しているため、テナントのデフォルト接続を設定する必要があります。- ［Auth0 Dashboard］>［Tenant Settings（テナント設定）］に移動し、下にスクロールして ［Default Directory（デフォルトディレクトリ）］ 設定を見つけます。
- 使用する接続の名前を入力します。ユーザー名とパスワードによるユーザー認証が可能であることを確認します。
トークンを要求する
APIを呼び出すには、まずユーザーの資格情報を取得しなければなりません。これは、通常、インタラクティブな形式で行います。アプリケーションは、受け取った資格情報をトークンと交換しなければなりません。これを行うには、トークンURLにPOSTする必要があります。
トークンURLへのPOSTの例
パラメーター
| パラメーター | 説明 |
|---|---|
grant_type | これをpasswordに設定します。 |
username | ユーザーが入力したユーザー名です。 |
password | ユーザーが入力したパスワードです。 |
client_id | アプリケーションのクライアントIDです。この値は［Application Settings（アプリケーションの設定）］にあります。 |
client_assertion | アプリケーション資格情報のある署名付きアサーションを含んだJWTです。アプリケーションの認証方法が秘密鍵JWTである場合は必須です。 |
client_assertion_type | 値はurn:ietf:params:oauth:client-assertion-type:jwt-bearerです。アプリケーションの認証方法が秘密鍵JWTである場合は必須です。 |
client_secret | アプリケーションのクライアントシークレットです。アプリケーションの認証方法がクライアントシークレットである場合は必須です。［Application Settings（アプリケーションの設定）］はPostまたはBasicです。アプリケーションの信頼性が高くない場合（SPAなど）には、このパラメーターを設定してはいけません。 |
audience | トークンのオーディエンス、つまりはAPIです。これはAPIの［Settings（設定）］タブの ［Identifier（識別子）］ フィールドにあります。 |
scope | 認可を要求したいスコープを指定します。これによって、受け取りたいクレーム（またはユーザー属性）が決定されます。スペース区切りでリストする必要があります。ユーザーについて任意の標準OpenID Connect（OIDC）スコープを要求できます。たとえば、profileやemail、名前空間形式に準拠したカスタムクレーム、呼び出すAPIが対応しているスコープ（read:contactsなど）を要求できます。を取得するには、offline_accessを含めます（［Application Settings（アプリケーションの設定）］)で__［Allow Offline Access（オフラインアクセスを許可する）］__フィールドが有効になっていることを確認してください）。 |
応答
すべてが成功すると、access_token、refresh_token、id_token、token_type、およびexpires_inの値を含むペイロードとともにHTTP 200応答を受信します。
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。
リフレッシュトークンは、ユーザーが実質的に永久に認証された状態を維持できるようにするため、安全に保管しなければなりません。
リソース所有者のパスワードのフローと標準スコープ
パスワードの提供でフルアクセス権が与えられるため、パスワードベースの交換ではすべてのスコープにアクセスできるようになります。たとえば、要求にAPIスコープを含めなくても、アクセストークンにはすべてのAPIスコープが含まれます。同様に、要求に
openidスコープだけを含めた場合でも、openid標準のOpenID Connectスコープがすべて返されます。これらの場合、応答にはscopeパラメーターが含まれ、その値は発行されたスコープのリストになります。ユーザー情報をIDトークンなしで取得する
ユーザー情報が必要な場合は、要求に
openidスコープを含めます。APIがRS256を署名アルゴリズムとして使用している場合は、アクセストークンに/userinfoが有効なオーディエンスとして含まれ、これを使うと/userinfoエンドポイントを呼び出してユーザーのクレームを取得することができます。APIを呼び出す
APIを呼び出すには、アプリケーションは、取得したアクセストークンをベアラートークンとしてHTTP要求の認証ヘッダーで渡さなければなりません。リフレッシュトークン
このチュートリアルに従って次の作業を完了している場合、あなたはすでにリフレッシュ トークンを受け取っています。- オフラインアクセスを許可するように、APIを構成する。
- 認可エンドポイントを通じて認証要求を開始するときに、
offline_accessスコープを含める。
grant_type=refresh_tokenを使用して、認証APIの/oauth/tokenエンドポイントに対してPOST要求を送信します。
トークンURLへのPOSTの例
パラメーター
| パラメーター名 | 説明 |
|---|---|
grant_type | これをrefresh_tokenに設定します。 |
client_id | アプリケーションのクライアントID。この値はアプリケーション設定で確認できます。 |
refresh_token | 使用するリフレッシュトークン。 |
scope | （任意）要求されたスコープの権限をスペースで区切ったリスト。送信されない場合は、元のスコープが使用されます。送信する場合は、スコープを減らして要求することができます。これはURLでエンコードされている必要があります。 |
応答
すべてが成功すると、新しいaccess_token、秒単位の有効期間（expires_in）、付与されたscope値、およびtoken_typeを含むペイロードとともにHTTP 200応答を受信します。
トークンは、検証してから保存します。操作方法については、「IDトークンの検証」および「アクセストークンを検証する」を参照してください。
サンプルユースケース
トークンをカスタマイズする
ルールを使用して、アクセストークンで返されたスコープを変更し、クレームをアクセスとIDトークンに追加することができます。（ルールの詳細については、「Auth0ルール」をお読みください。）これを行うには、ユーザーの認証後に実行される次のルールを追加します。Auth0は、プロファイル情報をOpenID Connect（OIDC）仕様で定義されている構造化クレーム形式で返します。つまり、IDトークンまたはアクセストークンに追加するカスタムクレームは、衝突を避けるためにガイドラインと制限に従わなければなりません。
レルムの対応を構成する
Auth0の拡張機能付与には、リソース所有者パスワード付与と似たような機能性がありますが、（別の接続にマッピングしている）別のユーザーディレクトリにして、フローで使用するものを個別に指定できるようになってます。 このバリエーションを使用するには、次のことを行う必要があります。grant_type要求パラメーターをhttp://auth0.com/oauth/grant-type/password-realmに設定します。realmという追加の要求パラメーターを送信し、それをユーザーが所属するレルムの名前に設定します。たとえば、内部の従業員用にemployeesという名前のデータベース接続を設定しており、そのユーザーがその接続に属している場合、realmをemployeesに設定します。
レルムとしての接続
データベース接続やパスワードレス接続、AD/LDAP、ADFS、Azure Active Directoryのエンタープライズ接続など、アクティブなアプリケーションに対応している接続はすべて、レルムとして構成できます。