デバイスコードフロー(OAuth 2.0 Device Authorization Grant).

OAuth 2.0 の Device Authorization Grant は RFC 8628 で規定され、通称デバイスコードフローと呼ばれます。使えるブラウザを持たないクライアント(スマート TV、CLI、キオスク、IoT 機器)が、ユーザーに別の機器で認証してもらうことで委任トークンを取得できる仕組みです。クライアントは IdP に device_code と短い user_code を要求し、user_code と検証 URL(例:https://microsoft.com/devicelogin)を表示します。ユーザーはその URL をスマートフォンや PC で開き、サインインして user_code を入力し同意します。その間クライアントは(interval を守り、slow_down では間隔を広げながら)トークン エンドポイントをポーリングし、IdP がトークンを発行するまで待ちます。このフローは gh auth login、az login --use-device-code、Apple TV のサインイン、Roku/Google TV のペアリングの基盤です。

同じ仕組みは強力なフィッシング経路でもあります。ユーザーは正規の IdP ページで認証するため、見破るべき偽ドメインが存在しないからです。攻撃者は標的テナントに対してデバイスコードフローを開始し、生成したての user_code を急かす文面で被害者に転送します。被害者が入力すると、トークンは攻撃者に発行されます。マイクロソフトの 2025 年 2 月の Storm-2372(2024 年 8 月から活動するロシア寄りのアクター)に関する報告はまさにこれを記録しています。Teams 会議を装ったおとりで政府・防衛・NGO の標的に攻撃者生成のコードを入力させ、得たトークンで Microsoft Graph 経由のメール窃取を行いました。防御策には、特定のアプリとユーザー グループを除いてフローを制限・無効化する条件付きアクセス ポリシー、短いトークン有効期間、そしてユーザー教育(デバイスコードは自分が開始したサインインのときだけ入力する)があります。

sequenceDiagram
  participant D as 機器(CLI/TV)
  participant I as ID プロバイダー
  participant U as ユーザー(スマホ/PC)
  D->>I: device_code と user_code を要求
  I-->>D: device_code, user_code, verification_uri
  D-->>U: 「URL を開きコードを入力」を表示
  loop ポーリング(interval / slow_down を遵守)
    D->>I: device_code でトークン エンドポイントを照会
    I-->>D: authorization_pending
  end
  U->>I: verification_uri を開き、サインインし、user_code を入力して同意
  I-->>D: アクセス トークンとリフレッシュ トークン
  Note over U,I: フィッシング リスク:攻撃者が自分の user_code を転送し<br/>トークンが攻撃者に発行される