Advanced OAuth

The core OAuth 2.0 framework is extended by a family of specifications. Each addresses a specific gap. You rarely need all of them, but knowing what exists helps you avoid building a custom mechanism.

Map of extensions

Device authorization grant (RFC 8628)

1. Device → POST /device_authorization (client_id, scope)
2. Device ← { device_code, user_code: "WDJB-MJHT", verification_uri, verification_uri_complete?, expires_in, interval }
3. Device shows: "Go to https://login.example.test/device and enter WDJB-MJHT" (or a QR code)
4. User signs in and approves on a phone or computer
5. Device polls POST /token grant_type=urn:ietf:params:oauth:grant-type:device_code&device_code=…
      ← authorization_pending | slow_down | access_denied | expired_token | tokens

The device must respect the polling interval and increase it on slow_down.

Risk: device-code phishing. An attacker starts a flow and persuades a victim to enter the code, then receives tokens for the victim’s account. Show the client’s name and requested access on the approval page, restrict the grant to clients that need it, and keep codes short-lived.

Token exchange (RFC 8693)

A client presents a token and receives another one at the token endpoint:

Uses include downscoping a token for a downstream service (authorization in APIs), impersonation (the new token represents the user), and delegation (the new token carries an act claim naming the actor, as for services and AI agents). The authorization server’s exchange policy is the security boundary.

Mutual TLS (RFC 8705)

RFC 8705 provides two things: client authentication with a TLS client certificate (tls_client_auth, self_signed_tls_client_auth), and certificate-bound tokens, where the token contains cnf.x5t#S256, the hash of the client certificate. The resource server checks that the TLS connection uses the same certificate. Compare with DPoP in DPoP.

JWT bearer grant (RFC 7523)

A client presents a signed JWT assertion, for example issued by a trusted identity system, and receives an access token. The same RFC defines private_key_jwt client authentication. Validate assertions strictly: issuer, audience, expiry, and one-time use.

Client-Initiated Backchannel Authentication (CIBA)

In CIBA, the client starts authentication without redirecting the user’s browser. The OpenID provider contacts the user on an authentication device, such as a banking app, and the client receives tokens by polling, ping, or push. Typical uses are call centers and point-of-sale payments.

OAuth 2.1 and security profiles

OAuth 2.1 consolidates OAuth 2.0 with the security lessons published since: PKCE for authorization-code flows, exact redirect URI matching, no bearer tokens in query strings, refresh token protection for public clients, and removal of the implicit and resource owner password credentials grants. Check its current status on the IETF datatracker; the practices it reflects are already recommended by RFC 9700.

For high-risk APIs such as open banking, the OpenID Foundation’s FAPI 2.0 Security Profile combines PAR, PKCE, sender-constrained tokens, and strong client authentication into a single, formally analyzed profile.

References

• Device Authorization Grant, RFC 8628.
• Token Exchange, RFC 8693.
• Mutual-TLS client authentication and certificate-bound tokens, RFC 8705.
• JWT Profile for Client Authentication and Authorization Grants, RFC 7523.
• OpenID Connect CIBA Core.
• OAuth 2.1 draft.
• FAPI 2.0 Security Profile.