メインコンテンツへスキップ
My Account API は Early Access で提供されています。アクセスをリクエストするには、Auth0 のアカウントマネージャーに連絡するか、Auth0 Support にお問い合わせください。Auth0 の製品リリースサイクルの詳細については、Product Release Stages を参照してください。
Auth0 My Account API は、ユーザーが自身のアカウント情報を管理するための専用のエンドポイント群を提供します。お客様はこれらの API を使用して、アプリケーション内にセルフサービス機能を構築したり、ユーザーアカウントに詳細情報を段階的に追加したりできます。 My Account API は、現在ログインしているユーザーのコンテキストで動作し、ユーザー向けアプリケーション内で直接使用できます。
Auth0 ドメインとカスタムドメインの使い分けMy Account API では、正規の Auth0 ドメインまたはカスタムドメインを使用できますが、以下を含むプロセス全体で同じドメインを使用する必要があります。
  • アクセストークンの取得
  • audience 値の設定
  • My Account API エンドポイントの呼び出し
詳細については、Custom Domains を参照してください。

​
My Account API を有効にする

で、テナントの My Account API を有効にできます。
  1. Applications > APIs に移動します。
  2. MyAccount API バナーを探します。
  3. Activate を選択します。
デフォルトでは、My Account API は次のアプリケーション API アクセスポリシーで作成されます。
  • ユーザーフローの場合は require_client_grant
  • クライアント (マシン間) フローの場合は deny_all
アプリケーションがユーザーに代わって My Account API にアクセスするには、そのアプリケーションのクライアントグラントを明示的に作成する必要があります。これにより、そのアプリケーションが要求できる最大スコープを定義できます。あるいは、ユーザーアクセスフローのポリシーを allow_all に変更することもできます。これにより、テナント内の任意のアプリケーションが My Account API に対して任意のスコープを要求できるようになります。 Auth0 では、ユーザーアクセスフローに allow_all を使用することは推奨していません。My Account API では機微な情報や操作が公開されるためです。アプリケーションが本当に必要なものにのみアクセスできるようにし、潜在的なセキュリティリスクを最小限に抑えるため、My Account API では最小権限の原則に従う必要があります。 アプリケーションに最終的に付与される権限は、アプリケーション API アクセスポリシーで許可されたスコープ、エンドユーザーに割り当てられた Role-Based Access Control (RBAC) の権限、およびユーザーの同意 (該当する場合) の積集合によって決まります。
My Account API へのクライアントアクセス用のアプリケーション API ポリシーは更新できません。つまり、Client Credentials Flow を使用して My Account API にアクセスすることはできません。
アプリケーション API アクセスポリシーと、それに関連付けられたクライアントグラントの管理方法について詳しくは、Application Access to APIs: Client Grants を参照してください。

​
デフォルトポリシー設定

My Account API の Authentication Assurance は現在、単一オプションのポリシーで提供される Early Access 段階です。この機能を使用すると、Okta の Master Subscription Agreement に記載されている該当する Free Trial 条項に同意したものとみなされます。Auth0 の製品リリースサイクルの詳細については、Product Release Stages を参照してください。プログラムへの参加を希望する場合は、Auth0 Support にお問い合わせください。
デフォルトポリシーは、Step-up Authentication を必須にすることで、My Account API に組み込みの認証保証を提供します。有効にすると、Auth0 はユーザーが直近に認証を行っており、かつ第 2 要素でも認証済みであることを自動的に強制します。 このポリシーでは、15 分以内に実施された 2FA を要求します。Auth0 はこのルールをログイン時と、すべてのリフレッシュトークン交換時に適用します。
  • ユーザーに登録済みの MFA 要素がある場合、ログイン時に 2FA を完了している必要があり、さらにトークンの経過時間が 15 分を超えると再度 2FA を完了する必要があります。
  • ユーザーに登録可能な要素がない場合、Auth0 は初回アクセスを許可しますが、15 分経過後のリフレッシュトークン交換では unmet_authentication_requirements エラーを返します。
デフォルトポリシーは Classic Login と互換性がありません。テナントで Universal Login またはサポートされている埋め込みフロー (Resource Owner Password Flow または native passkeys) を使用している場合に、この機能を有効にしてください。

​
デフォルトポリシー を有効にする

My Account API の デフォルトポリシー を有効にするには、次の手順に従います。
  1. Applications > APIs に移動し、My Account API を選択します。
  2. Settings タブを選択します。
  3. デフォルトポリシー で、Require 2FA をオンにします。
  4. Save を選択します。
テナントで デフォルトポリシー が有効になっている場合、新しい My Account API が作成されるたびに自動的に関連付けられます。

​
認証要件の階層

デフォルトポリシーは、テナントレベルの MFA ポリシーと、Actions で定義する MFA ロジックの中間に位置します。
  1. テナントの MFA ポリシー — テナント内のすべての認証に適用される基本のデフォルト
  2. デフォルトポリシー — My Account API に対してのみ、テナントレベルの設定を上書きします
  3. Actions — Actions 内の MFA コマンドは、常にこの両方より優先されます

​
デフォルトポリシーの動作

この動作は、ユーザーが登録可能な第2要素を持っているかどうかによって異なります。 MFA 要素が登録されているユーザー TOTP、メールアドレス、またはその他のサポートされている要素を登録しているユーザーの場合：
  1. ログイン時に、Auth0 はトークンを発行する前に、登録済みの要素でユーザーに追加認証を求めます。
  2. リフレッシュトークンには、認証方法とタイムスタンプ (AMR) が記録されます。
  3. 最後の追加認証から 15 分以内にリフレッシュトークンを交換した場合、Auth0 は再度追加認証を求めることなく新しいアクセストークンを発行します。
  4. 最後の追加認証から 15 分を過ぎてリフレッシュトークンを交換した場合、Auth0 はトークンを発行する前に再度ユーザーに追加認証を求めます。
MFA 要素が登録されていないユーザー 検証済みのメールアドレスがなく、登録済みの要素もないユーザーの場合：
  1. ログイン時に、Auth0 は第2要素なしでアクセスを許可します。
  2. 15 分以内にリフレッシュトークンを交換した場合、Auth0 は追加認証なしで新しいアクセストークンを発行します。
  3. 15 分を過ぎてリフレッシュトークンを交換した場合、Auth0 は unmet_authentication_requirements エラーを返します。
リフレッシュトークンの交換時に unmet_authentication_requirements が返された場合、そのトークンは更新できません。新しいトークンを取得するには、アプリケーションで認証フロー全体を最初からやり直す必要があります。15 分経過後にユーザーがポリシーの要件を満たせない場合は、サイレントログイン (prompt=none) でも同じエラーが返されます。

​
アクセストークンを取得する

My Account API のは、自分で管理する API のアクセストークンを取得する場合と同じ方法で取得できます。
デフォルトポリシー の要件を超える認証保証が必要な場合 (たとえば、特定の認証要素を必須にする、または一部の操作にのみ要件を適用する場合) は、step-up authentication と Actions を使用して、カスタム MFA ロジックを定義できます。なお、Actions は常に デフォルトポリシー より優先されます。
を使用している場合は、次の記事を参照してください。 埋め込みログインを使用している場合は、次の記事を参照してください。

​
対象者

My Account API のは https://{yourDomain}/me/ です。

​
スコープ

My Account API では、次のスコープをサポートしています。
スコープ説明
create:me:authentication_methodsユーザーは新しい認証方法を登録できます。
read:me:authentication_methodsユーザーは既存の認証方法を表示できます。
update:me:authentication_methodsユーザーは既存の認証方法を変更できます。
delete:me:authentication_methodsユーザーは既存の認証方法を変更できます。
read:me:factorsユーザーは登録可能な認証要素を表示できます。
Connected Accounts with Token Vault では、My Account API は次のスコープをサポートしています。
スコープ説明
create:me:connected_accountsユーザーは新しいアカウントを自分のユーザープロファイルに接続できます。
read:me:connected_accountsユーザーは自分のユーザープロファイルにリンクされている既存の接続済みアカウントを表示できます。
delete:me:connected_accountsユーザーは自分のユーザープロファイルから接続済みアカウントを削除できます。

​
例

​
認可コードフローを使用した Universal Login

ステップ 1: 認可コードをリクエストする
ステップ 2: code をアクセストークンに交換する

​
ネイティブパスキーによる埋め込みログイン

ステップ 1: ログインチャレンジを要求する
ステップ 2: 既存ユーザーを認証する

​
クロスオリジンリクエスト

Auth0 テナントとは異なるドメインで実行されるブラウザベースのアプリケーション (Single Page Application など) から My Account API を直接呼び出す場合、Cross-Origin Resource Sharing (CORS) と呼ばれるブラウザのセキュリティポリシーの制約を受けます。既定では、ブラウザはこのようなクロスオリジンリクエストをブロックします。 アプリケーションから API へのリクエストを正常に行えるようにするには、アプリケーションのドメイン (その「origin」) をクライアントの設定に追加する必要があります。
  1. Dashboard > Applications に移動します。対象のアプリケーションを選択します。
  2. Cross-Origin Authentication で、Allow Cross-Origin Authentication をオンにします。
  3. Allowed Origins (CORS) を見つけて、アプリケーションの origin URL を入力します。
  4. Save を選択します。
詳細については、Configure Cross-Origin Resource Sharing を参照してください。
アプリケーションで CORS を使用する必要がない場合は、Allow Cross-Origin Authentication がオフになっていることを確認してください。アプリケーションの URL をこの一覧に追加すると、その origin からのリクエストを Auth0 が信頼し、クライアントサイドアプリケーションから API にアクセスできるようになります。