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

保留中の Back-Channel Login リクエストのステータスを確認するには、トークンエンドポイントをポーリングします。

​

エンドポイント

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 トークンまたはアクセストークンと交換すると、その auth_req_id は以後使用できなくなります。

​

備考

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

• HTTP Basic認証を使用する Client Secret。この場合、パラメータは不要です。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 ヘッダーが必要です。

​

Body Parameters

リクエストボディは application/x-www-form-urlencoded 形式です。

client_id · string · 必須

アプリケーションの client_id。

auth_req_id · string · 必須

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

grant_type · string · 必須

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

​

レスポンスメッセージ

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