Auth0ドメインの使用とカスタムドメインの使用My Account APIは、正規のAuth0ドメインまたはカスタムドメインの使用をサポートしていますが、以下のプロセス全体で同じドメインを使用する必要があります。
- アクセストークンの取得
audience値の設定- My Account APIエンドポイントの呼び出し
My Account APIを有効にする
以下のように、:- **[アプリケーション]>[API]**に移動します。
- MyAccount APIのバナーを見つけます。
- **[アクティブ化]**を選択します。
![MyAccount APIバナーと[アクティブ化]ボタンが表示されたAuth0 DashboardのAPIページ](https://mintcdn.com/docs-dev-feat-docs-5569-member-mgmt/PFX1_z3zyGIRz99m/docs/images/cdy7uua7fh8z/DGkDQNIHcegN8vtQyEvF3/a2e98b06867701a66fa1f1b3df1c996b/My_Account_API_-_Activate.png?fit=max&auto=format&n=PFX1_z3zyGIRz99m&q=85&s=95dd5edaa57937744d60d8d605502915)
- ユーザーフローの場合は
require_client_grant - クライアント(マシンツーマシン)フローの場合は
deny_all
allow_allに変更すると、テナント内のすべてのアプリケーションがMy Account APIに対して任意のスコープをリクエストできるようになります。
My Account APIは機密情報や機密性の高い操作を公開しているため、Auth0ではユーザーアクセスフローにallow_allを使用することを推奨していません。My Account APIでは最小特権の原則に従い、アプリケーションが本当に必要なものだけにアクセスできるようにして、潜在的なセキュリティリスクを最小限に抑える必要があります。
Auth0は、アプリケーションAPIアクセスポリシーによって許可されるスコープや、エンドユーザーに割り当てられたRole-based Access Control(RBAC)の権限、ユーザーの同意(該当する場合)を突き合わせることで、アプリケーションに付与する最終的な権限を決定します。
My Account APIへクライアントがアクセスする際のアプリケーションAPIポリシーは更新できません。つまり、クライアントの資格情報フローを使用してMy Account APIにアクセスすることはできません。
デフォルトポリシー
デフォルトポリシーでは、ステップアップ認証を必須とすることで、My Account APIに組み込みの認証保証を提供します。有効にすると、Auth0は自動的に、ユーザーが最近認証を行ったことと、2つ目の要素を使用して認証していることを要求します。 このポリシーでは、15分以内での2FAの完了を要求します。Auth0は、ログイン時と、リフレッシュトークン交換のたびにこのルールを適用します。- ユーザーが登録済みのMFA要素を持っている場合、ログイン時に2FAを完了する必要があります。また、トークンの発行から15分を超えた後にも、再度2FAを完了する必要があります。
- ユーザーに登録可能な要素がない場合、Auth0は初回アクセスを許可しますが、15分経過後のリフレッシュトークン交換時に
unmet_authentication_requirementsエラーを返します。
デフォルトポリシーはクラシックログインと互換性がありません。テナントでユニバーサルログインまたはサポート対象の埋め込みフロー(リソース所有者のパスワードフローまたはネイティブパスキー)を使用している場合は、この機能を有効にしてください。
デフォルトポリシーを有効にする
My Account APIでデフォルトポリシーを有効にするには、次の手順を実行します。- [アプリケーション]>[API]に移動し、**[My Account API]**を選択します。
- **[設定]**タブを選択します。
- **[デフォルトポリシー]で[2FAを必須にする]**をオンにします。
- **[保存]**を選択します。
認証要件の優先順位
デフォルトポリシーは、テナントレベルのMFAポリシーと、Actionsで定義したMFAロジックの間に位置します。- テナントのMFAポリシー:ベースとなるデフォルトで、テナント内のすべての認証に適用されます。
- デフォルトポリシー:My Account APIに対して、テナントレベルのポリシーを上書きします。
- Actions:ActionsのMFAコマンドは、常に上記2つより優先されます。
デフォルトポリシーの動作
ユーザーに登録可能な2つ目の認証要素があるかどうかによって動作が異なります。 MFA要素を登録済みのユーザー TOTP、メール、その他のサポート対象の要素を登録しているユーザーの場合、以下のように動作します。- ログイン時、Auth0はトークンを発行する前に、登録済みの要素を使用して認証するようユーザーにチャレンジを行います。
- リフレッシュトークンには、認証方法とタイムスタンプ(AMR)が記録されます。
- 最後のチャレンジから15分以内にリフレッシュトークンを交換した場合、Auth0は再度チャレンジせずに新しいアクセストークンを発行します。
- 15分経過後にリフレッシュトークンを交換した場合、Auth0はトークンを発行する前に、再度ユーザーにチャレンジを行います。
- ログイン時、Auth0は2つ目の要素なしでアクセスを許可します。
- 15分以内にリフレッシュトークンを交換した場合、Auth0は再度チャレンジせずに新しいアクセストークンを発行します。
- 15分経過後にリフレッシュトークンを交換した場合、Auth0は
unmet_authentication_requirementsエラーを返します。
Auth0がリフレッシュトークンの交換時に
unmet_authentication_requirementsを返した場合、トークンのリフレッシュはできません。アプリケーションは、再度認証フロー全体を開始して、新しいトークンを取得する必要があります。サイレントログイン(prompt=none)でも、15分経過後にユーザーがポリシーの要件を満たせない場合は、同じエラーが返ります。アクセストークン取得する
を取得するのと同じ方法で、My Account APIのアクセストークンを取得できます。
を使用している場合、以下の記事を参照してください。
埋め込みログインを使用する場合には、次の記事を参照してください。
オーディエンス
はhttps://{yourDomain}/me/です。
スコープ
My Account APIは次のスコープをサポートしています。
トークンボールトを使用した接続済みアカウントでは、My Account APIで以下のスコープがサポートされています。
アクセストークンの例
認可コードフローを使用したユニバーサルログイン
Auth0のユニバーサルログインでアクセストークンを取得するには、2つのステップがあります。まず認可コードをリクエストし、次にそのコードをアクセストークンと交換します。この付与タイプについて詳しくは、「認可コードフロー」をご覧ください。 まず、/authorizeエンドポイントにAPI呼び出しを送信して、認可コードをリクエストします。
次に、コードをアクセストークンと交換します。
ネイティブパスキーを使用した埋め込みログイン
パスキーを埋め込みアプリケーションのログインフローに含めるには、まずログインチャレンジをリクエストします。 次に、既存のユーザーを認証します。認証方法を管理する
My Account APIを使用すると、エンドユーザーが自分の認証方法を登録・管理できるように、認証方法を設定できます。ほとんどの認証方法では、2段階のフローを使用します。まず登録を開始し、次に登録を確認します。 サポートされている認証方法については、以下の表をご覧ください。登録フロー
認証方法の登録は、2段階のプロセスで行います。- 登録を開始するには、メソッドのタイプと必要なフィールドを指定して、
/me/authentication-methodsに対してPOSTを送信します。Auth0は、auth_sessionトークンと、メソッドのタイプに応じた登録情報を返します。 - 登録を確認するには、
auth_sessionと、そのメソッドのタイプに応じた検証資格情報(OTPコード、新しいパスワード、またはWebAuthnレスポンス)を指定して、/me/authentication-methods/{id}/verifyに対してPOSTを送信します。
GETレスポンスで、Auth0はそのメソッドのconfirmedフィールドにtrueを設定します。
パスキーの登録では、
POSTレスポンスにIDは含まれません。Auth0は、検証ステップが成功した後にのみIDを返します。認証方法の管理の例
TOTP Authenticatorを登録する
TOTPの登録は、TOTP登録の開始とTOTP登録の確認という2段階のプロセスで行います。 まず登録を開始し、ユーザーがAuthenticatorアプリに追加するためのQRコードと手動入力用のシークレットを取得します。- 要求
- 応答
auth_sessionとidとともに送信して、登録を確認します。
- 要求
- 応答
認証方法の一覧を取得する
現在のユーザーが登録しているすべての認証方法を取得します。confirmedフィールドは、登録が完了しているかどうかを示します。
- 要求
- 応答
認証方法を削除する
登録済みの認証方法を削除します。{id}を、一覧取得のレスポンスで返されたその認証方法のidに置き換えます。
- 要求
- 応答
Cross-Originリクエスト
Auth0テナントとは異なるドメインで実行されているブラウザーベースのアプリケーション(シングルページアプリケーションなど)からMy Account APIを直接呼び出す場合、Cross-Origin Resource Sharing(CORS)と呼ばれるブラウザーのセキュリティポリシーが適用されます。デフォルトでは、ブラウザーはこのようなcross-originリクエストをブロックします。 アプリケーションがAPIに正常にリクエストできるようにするには、次の手順で、アプリケーションのドメイン(その「オリジン」)をクライアントの構成に追加する必要があります。- [ダッシュボード]>[アプリケーション]に移動します。[アプリケーション]ビューを選択します。
- **[Cross-Origin認証]で、[Cross-Origin認証を許可する]**をオンにします。
- **[許可されたオリジン(CORS)]**を見つけて、アプリケーションのオリジンURLを入力します。
- **[保存]**を選択します。
アプリケーションにCORSを使う必要がない場合は、**[Cross-origin認証を許可する]**が無効であることを確認してください。このリストにアプリケーションのURLを追加すると、Auth0はそのオリジンからのリクエストを信頼するようになり、クライアント側のアプリケーションからAPIにアクセスできるようになります。