Auth0 ドメインとカスタムドメインの使い分けMy Account API では、正規の Auth0 ドメインまたはカスタムドメインを使用できますが、次の項目を含め、プロセス全体を通じて同じドメインを使用する必要があります。
- アクセストークンを取得する
audienceの値を設定する- My Account API エンドポイントを呼び出す
My Account API を有効化する
で、テナントの My Account API を有効化できます。- Applications > APIs に移動します。
- MyAccount API バナーを見つけます。
- 有効化 を選択します。

- ユーザーフローには
require_client_grant - クライアント (machine-to-machine) フローには
deny_all
allow_all に変更することもできます。これにより、テナント内の任意のアプリケーションが My Account API の任意のスコープを要求できるようになります。
My Account API では機密情報や重要な操作が公開されるため、Auth0 はユーザーアクセスフローで allow_all を使用することを推奨していません。潜在的なセキュリティリスクを最小限に抑え、アプリケーションが本当に必要なものにのみアクセスできるようにするため、My Account API では最小権限の原則に従う必要があります。
Auth0 は、アプリケーション API アクセスポリシーで許可されたスコープ、エンドユーザーに割り当てられたロールベースのアクセス制御 (RBAC) の permissions、およびユーザーの同意 (該当する場合) の積集合によって、アプリケーションに最終的に付与される permissions を決定します。
My Account API へのクライアントアクセス用のアプリケーション API ポリシーは更新できません。つまり、クライアント認証情報フローを使用して My Account API にアクセスすることはできません。
デフォルトポリシー
デフォルトポリシー は、Step-up Authentication を必須にすることで、My Account API に組み込みの認証保証を提供します。有効にすると、Auth0 はユーザーが直近で認証されており、かつ第 2 認証要素を使用していることを自動的に適用します。 このポリシーでは、15 分以内の 2FA が必須になります。Auth0 はこのルールをログイン時と、すべてのリフレッシュトークン交換時に適用します。- ユーザーに登録済みの MFA 認証要素がある場合、2FA はログイン時に完了している必要があり、トークンの発行から 15 分を超えた場合は再度完了する必要があります。
- ユーザーに登録可能な認証要素がない場合、Auth0 は初回アクセスを許可しますが、15 分経過後のリフレッシュトークン交換では
unmet_authentication_requirementsエラーを返します。
デフォルトポリシー はクラシックログインと互換性がありません。テナントで Universal Login またはサポート対象の埋め込みフロー (Resource Owner Password Flow または Native パスキー) を使用している場合に、この機能を有効にしてください。
デフォルトポリシーを有効にする
My Account API のデフォルトポリシーを有効にするには、次の手順を実行します。- アプリケーション > APIs に移動し、My Account API を選択します。
- 設定 タブを選択します。
- デフォルトポリシー で、Require 2FA をオンにします。
- 保存 を選択します。
認証要件の階層
デフォルトポリシー は、テナントレベルの MFA ポリシーと、Actions で定義する MFA ロジックの中間に位置します。- テナント MFA ポリシー: テナント内のすべての認証に適用される基本のデフォルト設定
- デフォルトポリシー: My Account API に限り、テナントレベルの設定を上書きします
- Actions: Actions 内の MFA コマンドは、常にこの両方より優先されます
デフォルトポリシーの動作
この動作は、ユーザーが登録可能な第2認証要素を持っているかどうかによって異なります。 MFA認証要素を登録済みのユーザー TOTP、メール、またはその他のサポート対象の認証要素を登録しているユーザーの場合:- ログイン時に、Auth0 はトークンを発行する前に、登録済みの認証要素でユーザーにチャレンジを行います。
- リフレッシュトークンには、認証方法とタイムスタンプ (AMR) が記録されます。
- 最後のチャレンジから 15 分以内にリフレッシュトークン交換が行われた場合、Auth0 は再度チャレンジすることなく新しいアクセストークンを発行します。
- 15 分経過後にリフレッシュトークン交換が行われた場合、Auth0 はトークンを発行する前に、再度ユーザーにチャレンジを行います。
- ログイン時に、Auth0 は第2認証要素なしでアクセスを許可します。
- 15 分以内のリフレッシュトークン交換では、Auth0 はチャレンジなしで新しいアクセストークンを発行します。
- 15 分経過後のリフレッシュトークン交換では、Auth0 は
unmet_authentication_requirementsエラーを返します。
Auth0 がリフレッシュトークン交換で
unmet_authentication_requirements を返した場合、トークンを更新できません。新しいトークンを取得するには、アプリケーションで認証フロー全体を最初からやり直す必要があります。ユーザーが 15 分経過後にポリシーを満たせない場合、サイレントログイン (prompt=none) は同じエラーを返します。access token を取得する
My Account API のは、独自の API 向けの access token を取得する場合と同じ方法で取得できます。デフォルトポリシー を超える認証保証が必要な場合 (たとえば、特定の認証要素を必須にしたり、特定の操作にのみ要件を適用したりする場合) は、step-up authentication と Actions を使用して、カスタム MFA ロジックを定義できます。なお、Actions は常に デフォルトポリシー より優先されます。
Audience
My Account API の はhttps://{yourDomain}/me/ です。
スコープ
My Account API では、次のスコープがサポートされています。
Connected Accounts with Token Vault では、My Account API で次のスコープがサポートされています。
アクセストークンの例
認可コードフローでのUniversal Login
Auth0’s Universal Login でアクセストークンを取得するには、まず認可コードをリクエストし、次にそのコードをアクセストークンと交換するという2つの手順が必要です。このグラントタイプの詳細については、認可コードフローを参照してください。 まず、/authorize エンドポイントにAPI呼び出しを行って、認可コードをリクエストします。
次に、コードをアクセストークンと交換します:
Native パスキーを使用する埋め込みログイン
埋め込みアプリケーションのログインフローにパスキーを組み込むには、まずログインチャレンジをリクエストします。 次に、既存のユーザーを認証します。認証方法を管理する
My Account API を使用すると、認証方法を設定し、エンドユーザーが自分の認証方法を登録・管理できるようにします。ほとんどの認証方法では、登録を開始してから確認する 2 段階のフローを使用します。 サポート対象の認証方法については、次の表を確認してください。登録フロー
認証方法の登録は、次の 2 段階で行います。- 登録を開始するには、メソッドの種類と必要なフィールドを指定して、
/me/authentication-methodsにPOSTリクエストを送信します。Auth0 はauth_sessionトークンと、種類固有の登録情報を返します。 - 登録を確定するには、
auth_sessionとそのメソッドの種類に対応する検証用認証情報 (OTP コード、新しいパスワード、または WebAuthn レスポンス) を指定して、/me/authentication-methods/{id}/verifyにPOSTリクエストを送信します。
GET レスポンスで、メソッドの confirmed フィールドを true に設定します。
パスキーの登録では、
POST レスポンスに ID は含まれません。Auth0 が ID を返すのは、検証ステップが正常に完了した後のみです。認証方法の管理例
TOTP 認証器を登録する
TOTP の登録は、TOTP 登録の開始と確認の 2 段階で行います。 まず、登録を開始して、ユーザーが認証器アプリに追加するための QR コードと手動入力用シークレットを取得します。- リクエスト
- レスポンス
auth_session と id に、ユーザーの認証器アプリで生成されたワンタイムコードを添えて送信し、登録を確認します。
- リクエスト
- レスポンス
認証方法を一覧表示
現在のユーザーが登録しているすべての認証方法を取得します。confirmed フィールドは、登録が完了しているかどうかを示します。
- リクエスト
- レスポンス
認証方法をDelete
登録済みの認証方法を削除します。{id} は、一覧レスポンスに含まれる対象の認証方法の id に置き換えます。
- リクエスト
- レスポンス
クロスオリジン リクエスト
Auth0 テナントとは異なるドメインで実行されるブラウザベースのアプリケーション (Single Page Application など) から My Account API を直接呼び出す場合、クロスオリジン リソース共有 (CORS) と呼ばれるブラウザのセキュリティポリシーにより制限を受ける可能性があります。ブラウザはデフォルトで、こうしたクロスオリジン リクエストをブロックします。 アプリケーションから API に正常にリクエストを送信できるようにするには、アプリケーションのドメイン (「origin」) をクライアントの設定に追加する必要があります。- Auth0 Dashboard > アプリケーション に移動し、表示するアプリケーションを選択します。
- Cross-Origin Authentication で、Allow Cross-Origin Authentication をオンにします。
- Allowed Origins (CORS) を見つけて、アプリケーションの origin URL を入力します。
- 保存 を選択します。
アプリケーションで CORS を使用する必要がない場合は、Allow Cross-Origin Authentication がオフになっていることを確認してください。アプリケーションの URL をこのリストに追加すると、Auth0 はその origin からのリクエストを信頼し、クライアントサイドのアプリケーションから API へアクセスできるようになります。