カスタムトークン交換は、現在早期アクセス版として提供されています。Auth0のリリースについては、「製品のリリース段階」を参照してください。
/oauth/tokenエンドポイントを呼び出したときに既存のトークンをAuth0トークンに交換できるようにします。これは以下のような高度な統合に役立ちます。
- 別のオーディエンスのAuth0トークンを取得する
- 外部のIDプロバイダーを統合する
- Auth0に移行する
subject_token_typeとアクションが1対1でマッピングされます。アクション内にはカスタムコードを作成して、/oauth/tokenエンドポイントに渡されたサブジェクトトークンの復号化と検証を行うことができます。
カスタムトークン交換はユーザーの認証に使用できます。たとえば、アクション内でユースケースの認可ロジックを適用して、トランザクションにユーザーを設定できます。そうすると、Auth0がアクセストークン、IDトークンとリフレッシュトークンをユーザーに発行します。
カスタムトークン交換は、トランザクションでユーザーを識別するサブジェクトトークンの安全な検証を追加で担うことにより、トランザクションのユーザー設定に優れた柔軟性を提供します。カスタムトークン交換に使用するサブジェクトトークンは、必要なアクションコードが解釈できるのであれば、どのような形式や種類のトークンでも構いません。受信して受け入れるトークンに対して強固な検証を実装しなければなりません。 検証に不備があった場合、なりすましやリプレイ攻撃などのあらゆる攻撃にさらされることになり、悪意のある行為者が他者のユーザーIDを使用して認証できるようになります。サブジェクトトークンの安全な検証を実装する各種のオプションについては、「ユースケースの例とサンプルコード」に記載の推奨を読んだ上で適用してください。また、攻撃防御機能の適用も検討してください。
セットアップ
アプリケーション
- カスタムトークン交換はデフォルトで無効に設定されます。カスタムトークン交換を有効化するには、Management APIを使用してPOST呼び出しをクライアント作成エンドポイントに対して行うか、PATCH呼び出しをクライアント更新エンドポイントに対して行います。
token_exchangeのallow_any_profile_of_type属性を["custom_authentication"]に設定します。
- アプリケーションにデータベース接続またはエンタープライズ接続を有効化して、カスタムトークン交換で使用できるようにします。
- アプリケーションに[First-Party(ファーストパーティー)]フラグがあり、[Dashboard]>[Applications(アプリケーション)]>[Advanced Settings(詳細設定)]>[OAuth]で[OIDC Conformant(OIDC準拠)]として構成されていることを確認します。
カスタムデータベースは
setUserById操作にのみ対応しています。次回のカスタムトークン交換の EAリリースでは対応がsetUserByConnectionまで拡大される予定です。client_idとclient_secretを必ずメモして、後で/oauth/tokenエンドポイントを呼び出すときに使用できるようにします。
カスタムトークン交換プロファイル
subject_token_typeにマッピングされ、該当するユースケースのコードロジックがあるアクションと関連付けられます。
特定のsubject_token_type値を含めて/oauth/tokenエンドポイントに送信されたカスタムトークン交換要求は、対応するカスタムトークン交換プロファイルにマッピングされ、処理のために関連するアクションに送られます。
カスタムトークン交換プロファイルを作成するには、まずプロファイルにアクションを作成します。
アクションを作成する
- [Actions(アクション)] > [Library(ライブラリー)] に移動します。
- [Create Action(アクションを作成)] > [Build from scratch(初めから構築する)] を選択します。
- [Create Action(アクションを作成)] ダイアログに名前を入力し、ドロップダウンから [Custom Token Exchange(カスタムトークン交換)] トリガーを選択します。

- [Create(作成)] を選択します。
- アクションを [Deploy(デプロイ)] します。

- Auth0 DashboardでアクションIDを取得するには、ブラウザーウィンドウのURLを確認します。下の画像が示すように、アクションIDはURLの末尾の部分にあります。

/actionsエンドポイントに送信します。
actions[0].id内にアクションIDが含まれているはずです。アクションIDはカスタムトークン交換プロファイルの作成に必要です。
カスタムトークン交換プロファイルを作成する
/token-exchange-profilesエンドポイントに送信します。
| パラメーター | 説明 |
|---|---|
subject_token_type | 特有なプロファイルのトークンタイプのhttps://またはurnで始まるURIです。以下の名前空間は予約されているため使用できません。
|
action_id | カスタムトークンプロファイルに関連付けられているアクションのアクションIDです。 |
type | custom_authenticationに設定します。 |
カスタムトークン交換プロファイルを管理する
/token-exchange-profilesエンドポイントに要求を送信します。
カスタムトークン交換プロファイルを取得するには、以下の要求を行います。複数のプロファイルがある場合のために、このエンドポイントはチェックポイントページネーションに対応しています。
nameまたはsubject_token_typeを更新するには、以下のPATCH要求を行います。アクションIDは変更できませんが、実行されるカスタムコードはActionsエディターで変更できます。
Actions API
カスタムトークン交換とログイン後アクション
oauth2-token-exchangeと同じ値を持つevent.transaction.protocolを探します。トークン交換の付与タイプはカスタムトークン交換とネイティブソーシャルログインの両方のトランザクションで使用され、subject_token_typeはいずれかのカスタムトークン交換プロファイルに対応しているため、subject_token_type値を使用すれば、それらの2つを区別できます。
早期アクセス版のカスタムトークン交換は多要素認証に対応していません。MFAをテナントポリシーとして有効化することや、
api.multifactor.enable()、api.authentication.challengeWith()、api.authentication.enrollWith()の使用はカスタムトークン交換に未対応であるため、ログイン後アクショントリガー内においてトランザクションが回復不可能なエラーで失敗します。subject_token_type値に応じてevent.transaction.protocol==oauth2-token-exchange の場合にはMFAの有効化を必ずスキップしてください。MFA対応は次回のカスタムトークン交換のEAに追加される予定です。Actions APIを使用する
subject_token_typeに基づいてサブジェクトトークンの復号化と検証を行うアクションを実装してください。そうすることで、トランザクションのためにユーザー情報を入手できます。また、この情報を使用して、コードがトランザクションに必要な認可ポリシーを適用するようにします。トランザクションが続行できることを確認したら、対応するユーザーを設定してトランザクションを確定できます。そうすると、Auth0がアクセストークン、IDトークンとリフレッシュトークンをユーザーに発行します。これはユーザーを認証する1つの方法だと考えることができます。
カスタムトークン交換トランザクションはそれぞれ1つのテナントイベントログを生成します。トランザクションが成功すると種類がsecteのイベントログが生成され、トランザクションが失敗すると種類がfecteのイベントログが生成されます。これらの種類は受け取るかもしれないエラーを理解するのに役立ちます。/oauth/tokenエンドポイントからのエラーには詳細があまり含まれません。
カスタムトークン交換は、トランザクションでユーザーを識別するサブジェクトトークンの安全な検証を追加で担うことにより、トランザクションのユーザー設定に優れた柔軟性を提供します。カスタムトークン交換に使用するサブジェクトトークンは、必要なアクションコードが解釈できるのであれば、どのような形式や種類のトークンでも構いません。受信して受け入れるトークンに対して強固な検証を実装しなければなりません。 検証に不備があった場合、なりすましやリプレイ攻撃などのあらゆる攻撃にさらされることになり、悪意のある行為者が他者のユーザーIDを使用して認証できるようになります。サブジェクトトークンの安全な検証を実装する各種のオプションについては、「ユースケースの例とサンプルコード」に記載の推奨を読んだ上で適用してください。また、攻撃防御機能の適用も検討してください。
api.authentication.setUserById(user_id)
| パラメーター | 説明 |
|---|---|
user_id | ユーザーIDです。例:auth0|55562040asf0aef |
api.authentication.setUserByConnection(connection_name, user_profile, options)
setUserByConnection()を通してログインするたびに、ログイン回数が加算されます。このメソッドはユーザーがブロックされていると失敗します。
カスタムトークン交換のEA版は現在、エンタープライズ接続とソーシャル接続に加えて、Auth0のデータベース接続に対応しています。今後のカスタムトークン交換のEA版には、インポートモードが
OFFのカスタムデータベース対応が追加される予定です。| パラメーター | 説明 |
|---|---|
connection_name | ユーザープロファイルが設定される接続の名前です。512文字が上限です。 |
user_profile | 設定するユーザープロファイル属性を含むオブジェクトです。プロパティは24が上限です。 |
options | 更新と作成の動作を指定するオブジェクトです。{updateBehavior:'replace' | 'none',creationBehavior:'create_if_not_exists' | 'none',}ユーザーが存在する場合は、 updateBahaviourが以下を行います。
|
対応されているユーザープロファイル属性
setUserByConnection()メソッドでは、ユーザー更新エンドポイントが対応しているプロファイル属性を設定できます。
user_id(必須):この接続またはプロバイダーでユーザーに一意の識別子です。通常は、この接続について外部のIDプロバイダーが提供するユーザーIDです。このパラメーターはcreationBehaviourとupdateBehaviourの両方がnoneに設定されている場合にのみ必須です。emailemail_verified。デフォルトはfalseです。usernamephone_numberphone_verified。デフォルトはfalseです。namegiven_namefamily_namenicknamepicture
対応されている接続ストラテジー
setUserByConnection()メソッドが失敗します。他のストラテジーへの対応をご希望の場合には、Auth0サポートまでお問い合わせください。
エンタープライズ接続:
ソーシャル接続:
- カスタムソーシャル接続
- Apple
- Github
- Windowslive
作成の動作
creationBehaviorがcreate_if_not_existsに設定されている場合にのみ動的に作成されます。
ユーザーの作成には以下が必要です。
- 使用している接続に構成されている識別子を提供しなければなりません。メールはデフォルトで必須です。
- 柔軟な識別子と属性を使用する接続については、該当する属性が接続に有効化されていれば、ユーザー名や電話番号を提供できます。
-
柔軟な識別子と属性を使用しない接続については以下を行います。
- 接続に**[Require Username(ユーザー名を必須にする)]** が
trueに設定されている場合は、ユーザー名を提供できます。詳細については、「データベース接続にユーザー名を追加する」をお読みください。 phone_numberは提供できません。
- 接続に**[Require Username(ユーザー名を必須にする)]** が
-
email_verifiedやphone_verifiedを指定しても構いません。
ユーザーが接続に存在していない場合に、ユーザーを作成することなくログインさせるには、
creationBehaviorをnoneに設定します。今後のカスタムトークン交換では、接続の構成に応じてメール属性が任意になる予定です。更新の動作
updateBehaviorがreplaceに設定されている場合にのみ更新されます。
以下の属性は編集できません。値を変更しようとすると、Auth0からエラーが返されます。
emailusernamephone_numberemail_verifiedphone_verified
setUserByConnection()を使用して、すでにemail、username、またはphone_numberの属性を含むユーザープロファイルを更新にするには、それらの属性に既存の値を指定して渡す必要があります。そうしないと、メソッドがエラーを返します。ユーザーが接続にすでに存在する場合に、プロファイル属性を変更することなくログインさせるには、
updateBehaviorをnoneに設定します。メール検証
email_verified=falseでユーザーが作成されると、Auth0は自動的に確認メールを送信します。この動作をオーバーライドするには、verify_email=falseをユーザープロファイル属性として指定します。ユーザープロファイルの一部として保管はされません。
メタデータを設定する
setUserByConnection()メソッドではユーザーやアプリケーションのメタデータを設定できません。その場合はapi.user.setAppMetadataを使用できます。ユーザーメタデータの正しい使い方については、「ユーザープロファイルでのメタデータの仕組み」をお読みください。メタデータのベストプラクティスについては、「ログイン後トリガーでユーザーメタデータを管理する方法」をお読みください。
api.user.setAppMetadata(name, value)
nullに設定します。
| パラメーター | 説明 |
|---|---|
name | 文字列。メタデータプロパティの名前です。 |
value | 文字列、オブジェクト、配列。メタデータプロパティの値です。 |
api.user.setUserMetadata(name, value)
nullに設定します。
| パラメーター | 説明 |
|---|---|
name | 文字列。メタデータプロパティの名前です。 |
value | 文字列、オブジェクト、配列。メタデータプロパティの値です。 |
api.access.deny(code, reason)
| パラメーター | 説明 |
|---|---|
code | 応答でプロパティに含めて返される文字列です。 以下の2つの標準エラーコードを使用できます。
独自のエラーコードを使用する場合は、 400番台のステータスコードを返します。 |
reason | 応答のerror_descriptionプロパティに含めて返される文字列です。 |
api.access.rejectInvalidSubjectToken(reason)
invalid_requestのエラーコードを使用した400 Bad Requestエラー応答で拒否します。
試行の失敗が最大数に達すると、該当するIPアドレスからのすべてのカスタムトークン交換要求について、Auth0はトラフィックをtoo_many_attemptsのエラーコードを使用した429 Too Many Requestsエラー応答でブロックします。詳細については、「攻撃防御」をお読みください。
このメソッドは、署名や暗号化が不適切、または有効期限切れのサブジェクトトークンを含むカスタムトークン交換要求を受け取った場合には必ず使用してください。また、なりすましやリプレイ攻撃など、不正使用が疑われる状況でも必ず使用してください。そうすることで、Auth0は構成に応じて、不審なIPのスロットリングを適用できるようになります。
不審なIPのスロットリングはデフォルトで最大10回まで、1時間あたりに6回の試行を許容します。詳細については、「攻撃防御」をお読みください。
| パラメーター | 説明 |
|---|---|
reason | 応答でerror_descriptionプロパティに含めて返された文字列です。 |
api.cache
jwks-uriからキーを取得する際のパフォーマンスを向上させることができます。
api.cache.delete(key)
keyにキャッシュ済みの値が存在する場合は、それを記述したレコードを削除します。
値がキャッシュから削除されると、CacheWriteResultオブジェクトにtype: "success"を含めて返します。操作に失敗すると、type: "error"を返します。エラーの場合には、返すオブジェクトにcodeプロパティを含めて、失敗の詳細を示します。
| パラメーター | 説明 |
|---|---|
key | 文字列。キャッシュに保管されているレコードのキーです。 |
api.cache.get(key)
keyにキャッシュ済みの値が存在する場合は、それを記述したレコードを取得します。レコードが見つかった場合には、返されたオブジェクトのvalueプロパティにキャッシュ済みの値があります。
提供されたkeyにキャッシュが見つかった場合には、キャッシュレコードを返します。キャッシュレコードはvalueプロパティを含むオブジェクトで、このプロパティにはキャッシュ済みの値の他にもexpires_atプロパティが含まれ、レコードの最大有効期間をUNIXエポックからの経過ミリ秒数で示します。
重要: このキャッシュは、短命で一時的なデータ向けに設計されています。項目が所定のライフタイム内であったとしても、後のトランザクションでは利用できないかもしれません。
| パラメーター | 説明 |
|---|---|
key | 文字列。キャッシュに保管されているレコードのキーです。 |
api.cache.set(key, value, [options])
ttlまたはexpires_at値までのライフタイムがあります。ライフタイムが指定されない場合には、デフォルトのライフタイムである15分が使用されます。ライフタイムはアクションのキャッシュ制限が定める最大値を超過してはいけません。
値が正常に保管されると、CacheWriteSuccessを返します。それ以外の場合はCacheWriteErrorを返します。
| パラメーター | 説明 |
|---|---|
key | 文字列。キャッシュに保管されているレコードのキーです。 |
value | 文字列。保管するレコードの値です。 |
options | 任意のオブジェクト。キャッシュの動作を調整するオプションです。 |
options.expires_at | 任意の数値。UNIXエポックからのミリ秒単位で指定した絶対有効期限です。キャッシュ済みのレコードは早期に削除されることはあっても、expires_atで指定された時点を過ぎて存続することはありません。__注意:__この値がttlで指定されている場合は指定するべきではありません。両方で指定された場合、2つの中で早い方の有効期限が適用されます。 |
options.ttl | 任意の数値。このキャッシュエントリの存続時間をミリ秒単位で指定します。キャッシュ済みの値は早期に削除されることはあっても、ttlで指定された時点を過ぎて存続することはありません。__注意:__この値がexpires_atで指定されている場合は指定するべきではありません。両方で指定された場合、2つの中で早い方の有効期限が適用されます。 |
アクションイベント
| プロパティ | タイプ | 例 |
|---|---|---|
| client | ||
client_id | 文字列 | HOVc2PDFTH7eahimN4yNCo8mOtjfNjLV |
name | 文字列 | My Web App |
metadata | オブジェクト | {“foo”: “bar” } |
| tenant | ||
id | 文字列 | dev_1234 |
| request | ||
geoip | オブジェクト | { … geoip object} |
hostname | 文字列 | dev_1234.us.auth0.com |
ip | 文字列 | 123.42.42.34 |
user_agent | 文字列 | Mozilla/5.0 |
language | 文字列 | en |
body | オブジェクト | { // raw req.body } |
method | 文字列 | POST |
| transaction | ||
subject_token_type | 文字列 | urn://cic-migration-token |
subject_token | 文字列 | 41598922a1745f7af70 |
requested_scopes | 文字列[] | [“openid”, “email”] |
| resource_server | ||
id | 文字列 | http://acme-api/v1/profile |
アクションをデプロイする

トークン交換を呼び出す
POST要求を/oauth/tokenエンドポイントに対して行います。以下に留意してください。
- カスタムトークン交換に使用する
subject_tokensは、アクションコードが解釈できるのであれば、どのような形式や種類のトークンでも構いません。 subject_token_typeはそれぞれ特定のカスタムトークン交換プロファイルにマッピングされ、そのトランザクションを制御する特定のアクションに関連付けられます。
| パラメーター | 説明 |
|---|---|
grant_type | カスタムトークン交換には urn:ietf:params:oauth:grant-type:token-exchange を使用します。 |
subject_token_type | サブジェクトトークンの種類です。カスタムトークン交換では、独自に所有するURIでスコープが限定された任意の値です。たとえば、http://acme.com/legacy-tokenやurn:acme:legacy-token.です。以下の名前空間は予約されているため使用できません。
|
subject_token | アクションが検証とユーザーの識別に使用するべきサブジェクトトークンです。 |
client_id | トークン交換に使用しているアプリケーションのクライアントIDです。他の付与タイプについても、HTTP Basic認証でクライアントIDをAuthorizationヘッダーに含めて渡すことができます。 |
client_secret | トークン交換に使用しているアプリケーションのクライアントシークレットです。他の付与タイプについても、HTTP Basic認証でクライアントシークレットをAuthorizationヘッダーに含めて渡すことができます。 他にも方法はありますが、詳細についてはAuth0 Authentication APIのリファレンスドキュメントを参照してください。 公開アプリケーションがカスタムトークン交換を使用できることに注意してください。利用する場合は必ず「攻撃防御」をお読みください。 |
audience | Auth0で定義されているAPI識別子です。 |
scope | OAuth2スコープのパラメーターです。 |
event.request.bodyに含まれていますが、無視されます。
Organizationsはカスタムトークン交換の早期アクセスではまだ対応されていません。organizationパラメーターを使用すると、要求が拒否されます。Organizations対応は次のバージョンのカスタムトークン交換に追加する予定です。
要求例
攻撃防御
api.access.rejectInvalidSubjectTokenを使用してください。
不審なIPのスロットリングはAuth0テナントにはデフォルトでアクティブ化されます。アクティブ化や構成の方法については、「不審なIPのスロットリング」をお読みください。アクティブ化すると、カスタムトークン交換のデフォルト設定が適用されます。
- しきい値:10。1つのIPアドレスが失敗した試行の最大数です。
- スロットリングレート:1時間あたり6回。しきい値を超えない範囲で10分ごとに1回の試行が補充されます。

PATCH要求ではpre-custom-token-exchangeステージを必要な値で更新できます。レートは新たに試行が許可されるまでをミリ秒単位の間隔で表していることに注意してください。
ユースケースの例とサンプルコード
できる限り、そのままで使用できる通常のフェデレーションログインの使用をお勧めします。カスタムトークン交換はトランザクションにユーザーを設定可能にすることで、トランザクションの安全な検証と処理を強化し、柔軟性を向上します。
ユースケース:Auth0へシームレスに移行する

- モバイルアプリがAuth0に対してレガシーのリフレッシュトークンの交換を要求します。その際にはレガシーのリフレッシュトークンをサブジェクトトークンとして設定します。
- 該当するカスタムトークン交換プロファイルのアクションが実行されます。リフレッシュトークンをレガシーIdPで照会して、ユーザープロファイルから外部のユーザーIDを取得します。そして、必要な認可ポリシーを適用し、最終にユーザーを設定します。
- Auth0がAuth0のアクセストークン、IDトークン、リフレッシュトークンを含めて応答します。
- これで、ユーザーが再認証することなく、モバイルアプリがAuth0のトークンを使って顧客のAPIを使用できるようになりました。
- Auth0はユーザーを作成しません。
- Auth0はユーザープロファイルを更新しません。
ユースケース:外部の認証プロバイダーを再利用する

- ユーザーを認証したら、シングルページアプリが外部IdPからIDトークンを取得します。
- シングルページアプリがIDトークンをサブジェクトトークンとして設定し、トークンの交換を要求します。
- 該当するカスタムトークン交換プロファイルのアクションが実行されます。IDトークンを検証し、トークンからユーザーIDと他のプロファイル属性を取得します。そして、必要な認可ポリシーを適用し、最終にユーザーを設定します。
- Auth0がAuth0のアクセストークン、IDトークン、リフレッシュトークンを含めて応答します。
- これで、ユーザーが再認証することなく、SPAで実行中のJavascriptコードがAuth0のトークンを使って顧客のAPIを使用できるようになりました。
- Auth0は外部IdPのユーザーIDを使用して、該当する接続でユーザーを設定します。
- ユーザーが存在しない場合にはAuth0が作成します。
- ユーザーがすでに存在する場合のために、より完全な属性のセットがフェデレーションログインで取得できるのであれば、Auth0はユーザープロファイルを置換しません。
- Auth0はユーザーの作成時にメールを検証しません。
ユースケース:別のオーディエンスのAuth0トークンを取得する

- アプリが要求に当初のアクセストークンを含めてAPI Aに送信します。
- API Aのバックエンドサービスがアクセストークンを検証し、それをサブジェクトトークンとして設定して、API Bを使用するための新しいアクセストークンとの交換を要求します。
- 該当するカスタムトークン交換プロファイルのアクションが実行されます。IDトークンを検証し、トークンからAuth0ユーザーIDを取得します。そして、必要な認可ポリシーを適用し、最終にユーザーを設定します。
- Auth0がAPI Bオーディエンスを使用するためのAuth0のアクセストークンを含めて応答します。
- API Aのバックエンドサービスが新しいアクセストークンを使用してAPI Bを呼び出します。このアクセストークンは引き続き同じユーザーに関連付けられています。
- Auth0がAuth0のユーザーIDを使用してユーザーを設定するため、接続のスコープにこれを設定する必要はありません。
- Auth0はユーザーの作成や更新を行いません。
サンプルコード
強力なアルゴリズムと十分な高エントロピーのキーやシークレットで確実にサブジェクトトークンを保護することは、お客様の責任であることに注意してください。
非対称鍵で署名されたJWTを検証する
- Actionsのapi.cacheメソッドを使用し、トランザクションごとに署名鍵を取得しないようにします。
- RFC8725のベストプラクティスに従います。
- RS*、PS*、ES*、またはEd25519のアルゴリズムを使用します。
- noneアルゴリズムを使用したり、受け入れたりしてはいけません。
- 最小長2048ビットのRSAを使用します。
対称鍵で署名されたJWTを検証する
- Actionsシークレットを使用して、対称シークレットを安全に保管します。
- RFC8725のベストプラクティスに従います。
- HS256などのセキュリティ保護されたアルゴリズムと、高エントロピーでランダムなシークレット(256ビッドの最小長など)を使用します。
外部サービスで不透明なトークンを検証する
制限事項
- Organizations
- :ログイン後アクションの
api.authentication.challengeWith()およびapi.multifactor.enable()コマンドはカスタムトークン交換に未対応であるため、トランザクションが回復不可能なエラーで失敗します。同様に、テナントのポリシーとしてMFAが構成されている場合にも、トランザクションが失敗します。 - カスタムデータベース接続
- 特有のなりすまし対応(アクタートークンやアクタークレームなど)
- サードパーティやOIDC非準拠のクライアント
レート制限
/oauth/tokenエンドポイントに対するカスタムトークン交換要求には、該当するパフォーマンスレベルにおいて、Authentication APIのグローバルレート制限の10%というレート制限が適用されます。
| パフォーマンスレベル | グローバルのAuthentication API制限(RPS) | カスタムトークン交換制限(RPS) |
|---|---|---|
| Enterprise | 100 | 10 |
| プライベートクラウドベーシック(1x) | 100 | 10 |
| プライベートクラウドパフォーマンス(5x) | 500 | 50 |
| プライベートクラウドパフォーマンス(15x) | 1500 | 150 |
| プライベートクラウドパフォーマンス(30x) | 3000 | 300 |
| プライベートクラウドパフォーマンス(60x) | 6000 | 600 |
| プライベートクラウドパフォーマンス(100x) | 10000 | 1000 |
api/v2/token-exchange-profilesエンドポイントでの読み出し要求にも以下のレート制限が適用されます。
| パフォーマンスレベル | カスタムトークン交換の制限(RPS) | カスタムトークン交換の制限(RPM) |
|---|---|---|
| エンタープライズ | 20 | 200 |
| プライベートクラウドベーシック(1x) | 20 | 200 |
| プライベートクラウドパフォーマンス(5x) | 100 | 300 |
| プライベートクラウドパフォーマンス(15x) | 300 | 3000 |
| プライベートクラウドパフォーマンス(30x) | 600 | 6000 |
| プライベートクラウドパフォーマンス(60x) | 1200 | 12000 |
| プライベートクラウドパフォーマンス(100x) | 2000 | 20000 |
エンティティ制限
トラブルシューティング
「同意が必要」応答
/oauth/tokenエンドポイントを呼び出したときに、consent_requiredのエラー説明を含むinvalid_requestエラーを受け取ることがあります。
この問題を解消するには、Auth0 Dashboardを使用してAPIに**[Allow Skipping User Consent(ユーザー同意のスキップを許可する)]** オプションを有効にします。
