文字入力が難しい機器向けのサインイン

デバイスコード認証の待機・間隔延長・期限切れ状態と、別画面でのアカウント・権限確認を示す概念図

スマートテレビやキオスクでは、パスワードを入力するためのキーボードが使いにくいことがあります。OAuth 2.0 Device Authorization Grant は、機器が認可サーバーから device_code、利用者に表示する user_code、確認用 URI、有効期限、ポーリング間隔を受け取り、利用者が別のスマートフォンやパソコンでコードを入力して承認する方式です。その間、機器はトークンエンドポイントを一定間隔で確認します。RFC 8628 §§3.1–3.5

この方式が解決するのは入力の不便さです。機器の所有者や画面の前にいる人の身元を証明するものではありません。コードは、機器からの認可要求とブラウザーでの操作を結び付ける一時的な情報です。そのため、利用者が何を承認するのか分かる表示、有効期限、正しいポーリング処理が必要です。

ポーリング応答を状態として扱う

最初の応答に interval があれば、トークン要求の間にその秒数以上待ちます。値がない場合は RFC 8628 の既定規則に従います。利用者がまだ承認していないときの authorization_pending は、待機を続ける意味であり、間隔を詰めて連続要求する指示ではありません。slow_down を受け取ったらポーリング間隔を5秒増やし、その後も増加後の間隔を維持します。クライアントごとに独自の過剰な再試行を行い、認可サービスへ負荷をかける事態を防ぐ明示的な規則です。

device_code と user_code には有効期限があります。成功や期限切れなどの終了状態に達した値を使い続けてはいけません。通信タイムアウトは authorization_pending と異なります。プロトコル応答を受け取れていないため、サーバー側の状態を推測せず、回数を制限した通信再試行として扱います。一方、slow_down は明確な応答なので、直ちに待ち時間を変更します。状態を実装やログ上で区別すると、コード自体を漏らさずに障害を調べやすくなります。

承認画面で利用者が確認できること

機器画面には確認先の公式ドメインとコード入力方法を示し、別画面でアカウントや要求された権限を確認することを説明します。利用者が意図した機器や操作だと分かる情報をブラウザーにも表示します。電話やメッセージでコードを尋ねる相手は、攻撃者の機器を承認させようとしている可能性があります。コードを他人に伝えず、表示された公式アドレスか信頼できるリンクから確認ページへ進むよう案内します。広告や無関係な検索結果を認証先として信用しないことも大切です。

画面に出るコードは第三者に見られる可能性があるため、短い有効期間、推測困難なコード、入力試行の制限が必要です。認可サーバーは利用者コードの試行を制限し、別の人のコードが有効かどうかを応答の違いから容易に判別できないようにします。RFC 8628 はコード推測やリモートフィッシングをセキュリティ上の検討事項として扱いますが、各サービスの利用者・画面・サポート窓口に応じた評価までは代行しません。

専門家向け実装資料とその適用範囲

Microsoft identity platform の文書は、提供中のプラットフォームがこのフローをどう公開しているかを示す実務資料です。デバイスコード要求の応答に含まれるユーザーコード、確認 URI、有効期限、ポーリング間隔と、authorization_pending や slow_down の扱いを説明しています。また利用者がサインインする準備ができてから要求を始めるよう案内します。これは Microsoft の実装とガイダンスであり、すべての OAuth 提供者が同じ期限や応答を返すという意味ではありません。RFC は相互運用の規範を定め、提供者の文書は個別 API の使い方を示します。標準の状態遷移に従いつつ、選んだ提供者の現行フィールド、制限、エラー動作を確認してください。

実装では device_code を保護されたメモリー内で扱い、テレメトリーへ記録せず、終了エラーでポーリングを止めます。利用者が中止できるようにし、期限切れなら古い値を再利用せず、新しいフローを始める案内を出します。トークンを機器上で安全に保持できるか、同意をどう記録するか、不審な承認をどう調査するかは、プロトコルだけでは決まりません。

出典