Back-Channel Login フロー - ステータスの確認

Back-Channel Login フローのステータスを確認するには、次を指定して /oauth/token エンドポイントを一定間隔でポーリングします。

POST /oauth/token

Back-Channel Login フローのステータスを確認するには、次を指定して /oauth/token エンドポイントを一定間隔でポーリングします。

• /bc-authorize の呼び出しで返される auth_req_id
• urn:openid:params:grant-type:ciba グラントタイプ

​

レスポンス本文

認可するユーザーがまだリクエストを承認または拒否していない場合は、次のようなレスポンスが返されます。

{ 
  "error": "authorization_pending", 
  "error_description": "The end-user authorization is pending"
}

認可を行うユーザーがリクエストを拒否した場合、次のようなレスポンスが返されます。

{
  "error": "access_denied",
  "error_description": "The end-user denied the authorization request or it has been expired"
}

ポーリングの間隔が短すぎる場合 (/bc-authorize から返された interval 値よりも短い間隔) 、次のようなレスポンスが返されます。

{
  "error": "slow_down",
  "error_description": "You are polling faster than allowed. Try again in 10 seconds."
}

さらに、Auth0 はレスポンスに Retry-After ヘッダーを追加し、再度ポーリングを試みる前に何秒待機すべきかを示します。高頻度でポーリングし続けると、必要な待機時間 (秒) は長くなります。

認可するユーザーがプッシュ通知を承認すると、この呼び出しは IDトークン と アクセストークン (場合によっては リフレッシュトークン も) を返します。

{
  "access_token": "eyJh...",
  "id_token": "eyJh...",
  "expires_in": 86400,
  "scope": "openid"
}

auth_req_id を ID トークンまたはアクセストークンに交換すると、その後は使用できなくなります。

​

備考

リクエストには、アプリケーション認証用のオプションのパラメーターを含めます。

• HTTP Basic auth でクライアントシークレットを使用する場合、パラメーターは不要です。client_id と client_secret はヘッダーで渡されます。
• Client Secret Post の場合、client_id と client_secret が必要です。
• Private Key JWT の場合、client_id、client_assertion、および client_assertion type が必要です。
• mTLS の場合、client_id パラメーターに加えて、client-certificate ヘッダーと client-certificate-ca-verified ヘッダーが必要です。

​

パラメーター

client_id · string · 必須

アプリケーションの client_id。

auth_req_id · string · 必須

/bc-authorize エンドポイントから返された auth_req_id。

grant_type · string · 必須

urn:openid:params:grant-type:ciba に設定する必要があります。

​

レスポンス

ステータス	説明
200	認証のステータスが返されます。
400	不正なリクエスト - 無効なパラメーター
500	内部サーバーエラー