サードパーティアプリケーションのトラブルシューティング

Auth0 でサードパーティアプリケーションを扱う際によくあるエラーを解決します。

このページでは、サードパーティアプリケーションとの連携時によくあるエラーを解決できます。サードパーティアプリケーションの機能と制限の概要については、サードパーティアプリケーションのセキュリティ制御を参照してください。

​

サードパーティアプリケーションの問題を特定する

OAuthフロー中にエラーが発生した場合は、そのアプリケーションがサードパーティアプリケーションかどうかを確認してください。

• Client IDのプレフィックス: サードパーティアプリケーションの client_id は tpc_ で始まります。
• テナントのログ: Auth0 Dashboard > Monitoring > Logs でアプリケーションで絞り込み、エラーイベントを確認します。

​

よくあるエラー

​

トークンをリクエストすると unauthorized_client が返される

原因: サードパーティアプリケーションに、リクエスト先のAPIに対するクライアントグラントがありません。APIのアクセスポリシーが Allow All に設定されている場合でも、サードパーティアプリケーションには常に明示的なクライアントグラントが必要です。

解決策: アプリケーション用のクライアントグラントを作成するか、サードパーティアプリケーションのデフォルト権限を設定してください。詳しくは、Application Access to APIs: Client Grants を参照してください。

curl --request POST \
  --url 'https://YOUR_DOMAIN/api/v2/client-grants' \
  --header 'Authorization: Bearer YOUR_MANAGEMENT_API_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "default_for": "third_party_clients",
    "audience": "https://api.example.com",
    "scope": ["read:items", "write:items"],
    "subject_type": "user"
  }'

​

API ポリシーが「Allow All」でも unauthorized_client になる

原因: API のアクセスポリシー設定 Allow All は、ファーストパーティアプリケーションにのみ適用されます。サードパーティアプリケーションでは、この設定にかかわらず、常に明示的なクライアントグラントが必要です。

解決策: サードパーティアプリケーションのデフォルト権限を設定する か、アプリケーションごとに権限を作成してください。

​

サポートされていないパラメーターにより /authorize で invalid_request が発生する

原因: サードパーティアプリケーションでは、/authorize エンドポイントでパラメーターが厳密に検証されます。screen_hint、login_ticket、invitation、request (JAR) 、request_uri (PAR) などのパラメーターはサポートされていません。

解決策: 認可リクエストからサポートされていないパラメーターを削除してください。使用できるパラメーターの一覧については、サードパーティアプリケーションのセキュリティ制御を参照してください。

​

id_token または token に対する unsupported_response_type

原因: 暗黙的フロー (response_type=token または response_type=id_token) は、サードパーティアプリケーションでは利用できません。

解決策: PKCE を使用して、response_type=code を指定してください。

​

/oauth/token から ID トークンが返されない

原因: 強化されたセキュリティ制御が適用されたサードパーティアプリケーションでは、このリリースでは ID トークンは返されず、OIDC スコープ (openid、profile、email) も処理されません。トークンエンドポイントはアクセストークンを返しますが、id_token は返しません。

解決策: API スコープ付きのアクセストークンを使用して、アプリケーションに必要な情報を取得してください。サードパーティアプリケーション向けの OIDC サポートは、今後のリリースで提供される予定です。

​

サポートされていないグラントタイプ

原因: サポートされているグラントタイプは authorization_code、refresh_token、client_credentials のみです。implicit、password、urn:ietf:params:oauth:grant-type:device_code などのグラントタイプは使用できません。

解決策: ユーザーフローでは、PKCE を使用した認可コードフロー を使用してください。マシン間アクセスには、機密クライアントで Client Credentials Flow を使用してください (token_endpoint_auth_method は none 以外である必要があります) 。

​

Classic Login が動作しない

原因: Classic Login は、サードパーティアプリケーションではサポートされていません。

解決策: Universal Login を使用してください。Universal Login は、すべてのアプリケーションに推奨されるログイン方法です。

​

Client ID が tpc_ で始まる

原因: サードパーティアプリケーションの Client ID には、トラフィック分類のために自動的に tpc_ プレフィックスが付きます。これは作成時に付与され、変更できません。

解決策: これは想定どおりの動作です。より長い Client ID 形式に対応できるよう、クライアント側のバリデーションやデータベースの制約を更新してください。

​

is_first_party またはセキュリティモードは変更できません

原因: セキュリティモードとアプリケーションの所有形態は、作成時に確定する設計上の仕様であり、後から変更することはできません。

解決策: 必要な構成で新しいアプリケーションを作成してください。既存のアプリケーションを ファーストパーティ と サードパーティ の間で切り替えたり、セキュリティモードを変更したりすることはできません。

​

メール確認またはパスワードのリセットでエラーページが表示される

原因: アプリケーションの redirection_policy が open_redirect_protection に設定されているため、Auth0 はメールテンプレート内で application.callback_domain を公開しません。

解決策: サードパーティアプリケーション向けのフォールバックを含む Liquid の条件式を追加して、メールテンプレートを更新してください。

{% if application.callback_domain == '' %}
  https://YOUR_FALLBACK_DOMAIN
{% endif %}
{% if application.callback_domain != '' %}
  {{ application.callback_domain }}/result-page
{% endif %}

または、Dashboard または Management API で作成された信頼できるサードパーティアプリケーションに対して、redirection_policy を allow_always に設定します。詳しくは、サードパーティアプリケーションのセキュリティ制御を参照してください。

​

DCR クライアントがどの API にもアクセスできない

原因: 動的に登録されたクライアントは、トークンを要求する前にデフォルト権限を設定しておく必要があります。デフォルト権限が設定されていない場合、サードパーティの DCR クライアントはどの API にもアクセスできません。

解決策: DCR クライアントがアクセスする必要のある各 API で、サードパーティアプリケーション向けのデフォルト権限を設定してください。詳しくは、サードパーティアプリケーションを設定する を参照してください。

​

/userinfo がエラーを返す

原因: このリリースでは、/userinfo エンドポイントはサードパーティアプリケーションでは利用できません。

解決策: APIスコープのアクセストークンを使用して、アプリケーションに必要な情報を取得してください。/userinfo を含む OIDC のサポートは、今後のリリースで追加される予定です。

​

/oauth/revoke は使えるが、ログアウトエンドポイントは使えない

原因: ログアウトエンドポイント (/v2/logout) は、サードパーティアプリケーションでは利用できません。

解決策: リフレッシュトークンを取り消すには POST /oauth/revoke を使用します。セッションのクリアはアプリケーション側で行う必要があります。

​

サードパーティアプリケーションではコネクションを利用できません

原因: Organizationを使用しないフローでは、コネクションがドメインレベルに引き上げられていません。サードパーティアプリケーションでは、ドメインレベルのコネクションを通じてのみユーザーを認証できます。Organizationベースのフローでは、コネクションをOrganizationに対しても有効にする必要があります。

解決策: Organizationを使用しないフローでは、コネクションをドメインレベルに引き上げます。Organizationベースのフローでは、さらにOrganizationに対してコネクションを有効にする必要があります。

​

Organization 経由で認証する際の invalid_request

原因: Organization でサードパーティアプリケーションによるアクセスが有効になっていません。デフォルトでは、Organizations はサードパーティアプリケーションからの認証リクエストを拒否します。認可リクエストは invalid_request: parameter organization is invalid: {org_id} で失敗します。

解決策: 管理者は、Organization でサードパーティアプリケーションによるアクセスを有効にする必要があります。詳細については、「Organization のサードパーティアプリケーションによるアクセスを有効にする」をお読みください。

​

リフレッシュトークン のローテーションによる問題

原因: OAuth 2.1 の要件に従い、公開クライアント (SPA、Native) のサードパーティアプリケーションでは、デフォルトで リフレッシュトークン のローテーションが有効になっています。

解決策: トークンを交換するたびに新しい リフレッシュトークン が返され、以前のものが無効になるため、アプリケーションでローテーションされる リフレッシュトークン を正しく処理できていることを確認してください。管理者は、手動で作成したアプリケーションのローテーション設定を Dashboard または Management API で調整できます。

​

詳細はこちら

• サードパーティアプリケーション
• サードパーティアプリケーションのセキュリティ制御
• サードパーティアプリケーションの設定
• APIへのアプリケーションアクセス: クライアントグラント