認証APIは、Auth0を使用する際に、ユーザーのアイデンティティのあらゆる側面を管理できるようにします。エンドポイントを提供するため、ユーザーはログイン、サインアップ、ログアウト、APIへのアクセスなどを行うことができます。 APIは、OpenID Connect、OAuth 2.0、FAPIやSAMLなど、各種のアイデンティティプロトコルに対応しています。Documentation Index
Fetch the complete documentation index at: https://auth0-fix-auth-api-docs-migration-completion.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
ベースURL
認証APIはHTTPSを使用します。このドキュメントで参照されているURLはすべて次のベースに従っています：https://{yourDomain}
認証方法
このAPIを使用した認証には、5つのオプションがあります：- OAuth2 アクセストークン
- クライアントIDとクライアントアサーション（機密アプリケーション）
- クライアントIDとクライアントシークレット（機密アプリケーション）
- クライアントID（公開アプリケーション）
- mTLS認証（機密アプリケーション）
OAuth2アクセストークン
Bearer認証スキームを使用して、有効なアクセストークンをAuthorizationヘッダーに含めて送信します。
たとえば、ユーザー情報取得エンドポイントなどです。このシナリオでユーザーのプロファイルを取得するには、ユーザーの認証時にアクセストークンを取得し、そのトークンをAuthorizationヘッダーに含めてユーザー情報取得エンドポイントに要求を送信します。
クライアントIDとクライアントアサーション
認証するために、署名済みのJSON Web Token（JWT）を含むクライアントアサーションを生成します。要求本文には、クライアントID、urn:ietf:params:oauth:client-assertion-type:jwt-bearerの値を持つclient_assertion_typeパラメーター、署名済みのアサーションを指定するclient_assertionパラメーターを含めます。例については、「秘密鍵JWT」を参照してください。
クライアントIDとクライアントシークレット
クライアントIDとクライアントシークレットを送信します。このデータの送信に使用できるメソッドは、アプリケーションに構成されているトークンエンドポイントの認証方法により決定されます。 Postを使用している場合には、このデータを要求のJSON本文に含めて送信する必要があります。 Basicを使用している場合には、Basic認証スキームを使用して、このデータをAuthorizationヘッダーに含めて送信する必要があります。資格情報の値を生成する際には、クライアントIDとクライアントシークレットをコロン（:）で区切って連結し、Base64でエンコードします。
たとえば、リフレッシュトークン取り消しエンドポイントなどです。このオプションの使用は、機密アプリケーション（資格情報を認可されていないサードパーティーに公開することなく、安全に保持できるアプリケーションなど）のみに限定されます。
クライアントID
クライアントIDを送信します。公開アプリケーション（SPAやモバイルアプリなど、資格情報を安全に保持できないアプリケーション）については、クライアントIDのみでアクセス可能なエンドポイントをいくつか提供しています。 たとえば、暗黙的付与などです。mTLS認証
自己署名または認証局署名の証明書を生成します。そして、mTLSハンドシェイクを行うカスタマーエッジネットワークをセットアップします。 エッジネットワークが証明書を検証すると、次のヘッダーを使用して、要求がAuth0のエッジネットワークに転送されます：- カスタムドメインのAPIキーを
cname-api-keyヘッダーに含める - クライアント証明書を
client-certificateヘッダーに含める - クライアント証明書のCA検証ステータスを
client-certificate-ca-verifiedヘッダーに含める。詳細については、「要求を転送する」を参照してください。
パラメーター
GET要求では、パスでセグメントとして指定しないパラメーターはすべて、HTTPクエリ文字列パラメーターとして渡すことができます。GET https://{yourDomain}/some-endpoint?param=value¶m=value
POST要求では、URLに含めないパラメーターは、コンテンツタイプがapplication/jsonのJSONとしてエンコードする必要があります。
curl --request POST --url 'https://{yourDomain}/some-endpoint' --header 'content-type: application/json' --data '{"param": "value", "param": "value"}'
この例外はSAML IdP起点のシングルサインオン（SSO）フローで、クエリ文字列パラメーターと
x-www-form-urlencoded値の両方が使用されます。サンプルコード
それぞれのエンドポイントには、次の3つの形式でサンプルのスニペットが提供されています：- HTTP要求
- Curlコマンド
- JavaScript：エンドポイントによって、スニペットにはAuth0.jsライブラリー、Node.jsコードまたは簡素なJavaScriptが使用されます
application/jsonのコンテンツタイプで送信する必要があります。
テスト
エンドポイントはAuthentication API Debuggerを使用してテストすることができます。Authentication API Debugger
Authentication API DebuggerはAuth0の拡張機能で、使用すると、認証APIにあるいくつかのエンドポイントをテストすることができます。 デバッガーをインストール この拡張機能がすでにインストールされている場合には、スキップして、Authentication API Debuggerへ進んでください。 このリンクはテナントの地域に応じて異なります：米国西部、中央ヨーロッパまたはオーストラリア。テナントの地域の詳細については、「テナントの作成」を参照してください。接続を構成する
- *［構成］*タブで、［アプリケーション］フィールド（テストに使用するアプリケーションを選択）と［接続］（使用するソーシャル接続の名前）を設定します。
- Callback URLをコピーして、アプリケーションの設定にある**［許可されているコールバックURL］**に追加します。
- *［OAuth2 / OIDC］*タブで、**［OAuth2 / OIDCログイン］**を選択します。
エンドポイントのオプション
他のエンドポイントを次のオプションで構成します：- パスワードレス：*［OAuth2 / OIDC］*タブで、**［ユーザー名］に
connection=smsの場合にはユーザーの電話番号、connection=emailの場合にはユーザーのメールを設定し、［パスワード］にユーザーの確認コードを設定します。［リソース所有者エンドポイント］**をクリックします。 - SAML SSO：*［他のフロー］*タブで、**［SAML］**を選択します。
- WS-Federation：*［他のフロー］*タブで、**［WS-Federation］**を選択します。
- ログアウト：*［他のフロー］*タブで、**［ログアウト］を選択するか、IDプロバイダーからもログアウトさせる場合には［ログアウト（フェデレーション）］**を選択します。
- レガシーログイン：*［OAuth2 / OIDC］*タブで、［IDトークン］、［リフレッシュトークン］、**［対象クライアントID］を設定します。［委任］**をクリックします。
- レガシーの委任：*［OAuth2 / OIDC］*タブで、**［ユーザー名］と［パスワード］を設定します。［リソース所有者エンドポイント］**をクリックします。
- レガシーのリソース所有者：*［OAuth2 / OIDC］*タブで、**［ユーザー名］と［パスワード］を設定してから、［リソース所有者エンドポイント］**を選択します。
認証フロー
認証フローを次のオプションで構成します：- 認可コードフロー：*［OAuth2 / OIDC］*タブで、**［認可コード］フィールドに認可コード付与で取得したコードを設定し、［コード検証］にキーを設定します。［OAuth2コード交換］**をクリックします。
- 認可コードフロー＋PKCE：*［OAuth2 / OIDC］*タブで、**［認可コード］フィールドに認可コード付与で取得したコードを設定し、［コード検証］にキーを設定します。［OAuth2コード交換］**をクリックします。
- クライアント資格情報フロー：*［OAuth2 / OIDC］*タブで、**［OAuth2クライアント資格情報］**を選択します。
エラー
エラーが発生すると、エラーオブジェクトを受け取ります。ほとんどのエラーオブジェクトにはエラーコードとエラーの説明が含まれているため、アプリケーションは効率よく問題を特定することができます。4xx HTTP応答コードを受け取った場合には、送信した要求が不正であったと考えて間違いありません。
5xxエラーはAuth0側での問題を示唆しているため、Auth0のステータスページやTwitterの@auth0statusでシステムの状態を確認してください。
その他の場合には、Auth0サポートのオプションを使用することができます。
レート制限
認証APIはレート制限の対象になります。制限はエンドポイントによって異なります。 エンドポイントで指定のレート制限を超過すると、次のメッセージを含む429 Too Many Requests（要求が多すぎます）応答を受け取ります：Too many requests. Check the X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset headers.
レート制限の詳細については、「Auth0 APIのレート制限ポリシー」を参照してください。
データベース接続の場合、ユーザーアカウントやIPアドレスによっては、ある種のログイン試行の反復が制限されます。詳細については、「ユーザー/パスワード認証でのレート制限」を参照してください。