Auth Internals & OAuth2 — Series 3

Preview — 3 of 10 questions

What problem does this grant solve?

javascript

POST /oauth/device_authorization
→ { device_code, user_code: "WDJB-MJHT", verification_uri, interval: 5 }

AIt authenticates the device itself, with no user involved

BIt replaces the authorisation code grant on mobile

CA CLI, a TV or a headless tool cannot host a redirect URI or safely render a login form, so the device shows a short code, the user authorises it on a phone or laptop, and the device polls the token endpoint at the stated interval until the authorisation completes

DIt allows a device to authorise itself by presenting a hardware certificate

What does that imply?

javascript

A single-page application and a mobile app both hold refresh tokens.
Neither can keep a client secret.

ARotation with reuse detection becomes mandatory rather than optional: a public client cannot prove it is the legitimate holder, so the only defence against a stolen refresh token is that using it twice reveals the theft and revokes the family

BPublic clients must not receive refresh tokens under any circumstances

CThe refresh token should simply be given a very long lifetime to reduce round trips

DThe client secret can be embedded safely if the application is obfuscated

What does this claim do?

javascript

// id_token payload
{ "sub": "u_1", "aud": "web-app", "at_hash": "xQ8Z9..." }

AIt stores a hash of the user's password for the client to verify

BIt identifies which signing key produced the access token

CIt is a random value preventing replay, equivalent to nonce

DIt binds the ID token to the access token issued alongside it — the client hashes the access token and compares — so an attacker cannot pair a legitimate ID token with an access token obtained elsewhere

Answer all 10 questions (7 more), see explanations for every answer, and track your score.