Skip to main content
Auth0 My Account APIは、ユーザーが自分のアカウント情報を管理するための専用エンドポイントを提供します。これらのAPIを使用して、アプリケーション内にセルフサービス機能を構築したり、ユーザーアカウントに詳細情報を段階的に追加したりできます。 My Account APIは、現在ログインしているユーザーのコンテキスト内で動作し、ユーザー向けアプリケーション内で直接使用できます。
Auth0ドメインの使用とカスタムドメインの使用My Account APIは、正規のAuth0ドメインまたはカスタムドメインの使用をサポートしていますが、以下のプロセス全体で同じドメインを使用する必要があります。
  • アクセストークンの取得
  • audience値の設定
  • My Account APIエンドポイントの呼び出し
詳細については、「カスタムドメイン」をご覧ください。

My Account APIを有効にする

以下のように、
  1. **[アプリケーション]>[API]**に移動します。
  2. MyAccount APIのバナーを見つけます。
  3. **[アクティブ化]**を選択します。
MyAccount APIバナーと[アクティブ化]ボタンが表示されたAuth0 DashboardのAPIページ
デフォルトでは、Auth0はMy Account APIを作成する際、アプリケーションAPIアクセス ポリシーとして以下を設定します。
  • ユーザーフローの場合はrequire_client_grant
  • クライアント(マシンツーマシン)フローの場合はdeny_all
ユーザーに代わってMy Account APIにアクセスするアプリケーションに対しては、明示的にそのアプリケーション用のクライアント付与を作成して、アプリケーションがリクエストできるスコープの最大数を定義できるようにする必要があります。あるいは、ユーザーアクセスフローのポリシーを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にアクセスすることはできません。
アプリケーションAPIアクセスポリシーとそれに関連するクライアント付与を管理する方法について詳しくは、「APIへのアプリケーションアクセス:クライアント付与」をご覧ください。

デフォルトポリシー

デフォルトポリシーでは、ステップアップ認証を必須とすることで、My Account APIに組み込みの認証保証を提供します。有効にすると、Auth0は自動的に、ユーザーが最近認証を行ったことと、2つ目の要素を使用して認証していることを要求します。 このポリシーでは、15分以内での2FAの完了を要求します。Auth0は、ログイン時と、リフレッシュトークン交換のたびにこのルールを適用します。
  • ユーザーが登録済みのMFA要素を持っている場合、ログイン時に2FAを完了する必要があります。また、トークンの発行から15分を超えた後にも、再度2FAを完了する必要があります。
  • ユーザーに登録可能な要素がない場合、Auth0は初回アクセスを許可しますが、15分経過後のリフレッシュトークン交換時にunmet_authentication_requirementsエラーを返します。
デフォルトポリシーはクラシックログインと互換性がありません。テナントでユニバーサルログインまたはサポート対象の埋め込みフロー(リソース所有者のパスワードフローまたはネイティブパスキー)を使用している場合は、この機能を有効にしてください。

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

My Account APIでデフォルトポリシーを有効にするには、次の手順を実行します。
  1. [アプリケーション]>[API]に移動し、**[My Account API]**を選択します。
  2. **[設定]**タブを選択します。
  3. **[デフォルトポリシー][2FAを必須にする]**をオンにします。
  4. **[保存]**を選択します。
テナントでデフォルトポリシーを有効にすると、Auth0は新しいMy Account APIを作成するたびに、デフォルトポリシーを自動的に適用します。

認証要件の優先順位

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

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

ユーザーに登録可能な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エラーを返します。
Auth0がリフレッシュトークンの交換時にunmet_authentication_requirementsを返した場合、トークンのリフレッシュはできません。アプリケーションは、再度認証フロー全体を開始して、新しいトークンを取得する必要があります。サイレントログイン(prompt=none)でも、15分経過後にユーザーがポリシーの要件を満たせない場合は、同じエラーが返ります。

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

を取得するのと同じ方法で、My Account APIのアクセストークンを取得できます。
デフォルトポリシーよりも高度な認証保証が必要な場合(たとえば、特定の要素を必須にしたり、特定の操作にのみ要件を適用したりする場合)は、Actionsを使用したステップアップ認証によって、カスタムMFAロジックを定義できます。Actionsは常にデフォルトポリシーより優先されることに注意してください。
を使用している場合、以下の記事を参照してください。 埋め込みログインを使用する場合には、次の記事を参照してください。

オーディエンス

https://{yourDomain}/me/です。

スコープ

My Account APIは次のスコープをサポートしています。 トークンボールトを使用した接続済みアカウントでは、My Account APIで以下のスコープがサポートされています。

アクセストークンの例

認可コードフローを使用したユニバーサルログイン

Auth0のユニバーサルログインでアクセストークンを取得するには、2つのステップがあります。まず認可コードをリクエストし、次にそのコードをアクセストークンと交換します。この付与タイプについて詳しくは、「認可コードフロー」をご覧ください。 まず、/authorizeエンドポイントにAPI呼び出しを送信して、認可コードをリクエストします。 次に、コードをアクセストークンと交換します。

ネイティブパスキーを使用した埋め込みログイン

パスキーを埋め込みアプリケーションのログインフローに含めるには、まずログインチャレンジをリクエストします。 次に、既存のユーザーを認証します。

認証方法を管理する

My Account APIを使用すると、エンドユーザーが自分の認証方法を登録・管理できるように、認証方法を設定できます。ほとんどの認証方法では、2段階のフローを使用します。まず登録を開始し、次に登録を確認します。 サポートされている認証方法については、以下の表をご覧ください。

登録フロー

認証方法の登録は、2段階のプロセスで行います。
  1. 登録を開始するには、メソッドのタイプと必要なフィールドを指定して、/me/authentication-methodsに対してPOSTを送信します。Auth0は、auth_sessionトークンと、メソッドのタイプに応じた登録情報を返します。
  2. 登録を確認するには、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コードと手動入力用のシークレットを取得します。
次に、ユーザーのAuthenticatorアプリから取得したワンタイムコードを、前のレスポンスで返されたauth_sessionidとともに送信して、登録を確認します。

認証方法の一覧を取得する

現在のユーザーが登録しているすべての認証方法を取得します。confirmedフィールドは、登録が完了しているかどうかを示します。

認証方法を削除する

登録済みの認証方法を削除します。{id}を、一覧取得のレスポンスで返されたその認証方法のidに置き換えます。

Cross-Originリクエスト

Auth0テナントとは異なるドメインで実行されているブラウザーベースのアプリケーション(シングルページアプリケーションなど)からMy Account APIを直接呼び出す場合、Cross-Origin Resource Sharing(CORS)と呼ばれるブラウザーのセキュリティポリシーが適用されます。デフォルトでは、ブラウザーはこのようなcross-originリクエストをブロックします。 アプリケーションがAPIに正常にリクエストできるようにするには、次の手順で、アプリケーションのドメイン(その「オリジン」)をクライアントの構成に追加する必要があります。
  1. [ダッシュボード]>[アプリケーション]に移動します。[アプリケーション]ビューを選択します。
  2. **[Cross-Origin認証]で、[Cross-Origin認証を許可する]**をオンにします。
  3. **[許可されたオリジン(CORS)]**を見つけて、アプリケーションのオリジンURLを入力します。
  4. **[保存]**を選択します。
詳しくは、「Cross-Originリソース共有を構成する」をご覧ください。
アプリケーションにCORSを使う必要がない場合は、**[Cross-origin認証を許可する]**が無効であることを確認してください。このリストにアプリケーションのURLを追加すると、Auth0はそのオリジンからのリクエストを信頼するようになり、クライアント側のアプリケーションからAPIにアクセスできるようになります。