入力制約を回避する
リモコンやCLIで長いパスワードを入力せず、普段利用するスマートフォンの安全なブラウザでログインできます。
Overview
この仕様は、
何を解決するのか。
テレビアプリ、CLI、IoTなど、通常のブラウザリダイレクトを利用しにくいClientを設計する人向けです。Device Authorization Grantは、テレビ、ゲーム機、プリンター、CLIのように、文字入力やブラウザ操作が難しい端末を認可するためのOAuth 2.0拡張です。認可を必要とする端末と、ユーザーがログインする端末を分けます。
対象端末は短いuser_codeとverification_uriを表示します。ユーザーはスマートフォンなど操作しやすい端末でコードを入力して承認し、対象端末は承認結果をToken Endpointへ問い合わせます。対象端末へパスワードを入力する必要はありません。
Purpose and responsibilities
仕様が定める、大切なこと。
端末を明確に承認する
user_codeによって、スマートフォン上の承認操作と、認可を待っている対象端末を結び付けます。
非同期に結果を待つ
対象端末はdevice_codeを使って結果をpollし、承認が終わるまでauthorization_pendingを処理します。
Key concepts
01Device Code02User Code03Verification URI04Token Polling
Security considerations
安全に使うための確認事項。
仕様を実装するときは、正常系の通信だけでなく、値のすり替え、再利用、漏えいが起きた場合も考えます。
- 01
user_codeとdevice_codeは別の値として扱い、device_codeを画面へ表示しません。
- 02
expires_inを過ぎた要求を拒否し、device_codeは一度だけ使用可能にします。
- 03
intervalを守り、slow_downを受け取った場合は問い合わせ間隔を延ばします。
- 04
承認画面に対象端末、Client名、要求scopeを表示し、ユーザーが意図した要求か確認できるようにします。
Interactive flows
この仕様に属するフロー
Position and relationship
ほかの仕様との関係
RFC 8628はRFC 6749の拡張Grantです。OpenID Connectのopenid scopeと組み合わせれば認証にも利用できますが、CIBAとは開始方法が異なります。Device Flowは端末にコードを表示し、CIBAはClientがユーザー識別子を使って別端末へ認証要求を開始します。
Other specifications
OAuth 2.0 (RFC 6749)The OAuth 2.0 Authorization Framework→OAuth 2.1OAuth 2.1 Authorization Framework→OpenID Connect Core 1.0OpenID Connect Core 1.0→FIDO2 WebAuthn Level 3Web Authentication: Public Key Credentials→FIDO2 CTAP 2.2Client to Authenticator Protocol→FIDO UAF 1.1Universal Authentication Framework→FIDO U2F 1.2Universal Second Factor→OpenID Connect CIBA Core 1.0Client-Initiated Backchannel Authentication→OAuth 2.0 PKCE (RFC 7636)Proof Key for Code Exchange by OAuth Public Clients→JSON Web Token (RFC 7519)JSON Web Token (JWT)→OAuth 2.0 DPoP (RFC 9449)OAuth 2.0 Demonstrating Proof of Possession→SAML 2.0Security Assertion Markup Language 2.0→SCIM 2.0 (RFC 7644)System for Cross-domain Identity Management: Protocol→