OAuth.

Some quick references to various OAuth documents that I find myself repeatedly looking up, for work.

Registry of parameters#

This is a super helpful all-up view of the exact parameter names from various OAuth RFCs.

https://www.iana.org/assignments/oauth-parameters

The main RFC's#

• RFC 6749 The OAuth 2.0 Authorization Framework
• RFC 9700 BCP 240: Best Current Practice for OAuth 2.0 Security

Authorizing your TV or fridge#

Device Authorization Grant 8628 is the RFC that breaks that flow down.

Requirements

1. The device is already connected to the Internet.
2. The device is able to make outbound HTTPS requests.
3. The device is able to display or otherwise communicate a URI and code sequence to the user.
4. The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request.

Authorization Server Metadata#

An authorization server's means of advertising its configuration and supported features to clients.

Here's example data from https://clerk.thekevinwang.com/.well-known/openid-configuration. Another valid endpoint is https://clerk.thekevinwang.com/.well-known/oauth-authorization-server.

{issuer: "https://clerk.thekevinwang.com",authorization_endpoint: "https://clerk.thekevinwang.com/oauth/authorize",token_endpoint: "https://clerk.thekevinwang.com/oauth/token",revocation_endpoint: "https://clerk.thekevinwang.com/oauth/token/revoke",introspection_endpoint: "https://clerk.thekevinwang.com/oauth/token_info",userinfo_endpoint: "https://clerk.thekevinwang.com/oauth/userinfo",jwks_uri: "https://clerk.thekevinwang.com/.well-known/jwks.json",scopes_supported: […],response_types_supported: […],response_modes_supported: […],grant_types_supported: […],subject_types_supported: […],id_token_signing_alg_values_supported: […],token_endpoint_auth_methods_supported: […],claims_supported: […],code_challenge_methods_supported: […],backchannel_logout_supported: false,frontchannel_logout_supported: false,authorization_response_iss_parameter_supported: true}

FAQ#

Q: Which parties govern the aud claim in an access token?#

RFC 8707 §2.2 leaves acceptable resources to authorization-server policy and configuration ¹

RFC 9068 §3 also leaves scope-to-default-resource mappings to the implementation. ²

RFC 9728 §4 An authorization server can publish an optional protected_resources list in its metadata. However, that list can omit supported resources, so it is not necessarily the canonical database. ³

Q: What is the Step up flow?#

Allows a resource server to request a client to obtain a new access token with a higher level of authentication and or recency.

RFC 9470⁴ extends RFC 6750⁵ with new parameters and a new error code:

Name	Usage Location	Protocol Extension	Ref
acr_values	authorization request		https://openid.net/specs/openid-connect-core-1_0.html
max_age	authorization request		https://openid.net/specs/openid-connect-core-1_0.html
insufficient_user_authentication	resource access error response	OAuth 2.0 Step Up Authentication Challenge Protocol	RFC 9470

The resource server can use these parameters to explicitly communicate to the client the required authentication strength or recentness.

Client then makes an auth request to AS w/ acr_values and max_age.

Footnotes#

1. RFC 8707 Resource Indicators for OAuth 2.0: https://www.rfc-editor.org/info/rfc8707 ↩

2. RFC 9068 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens: https://www.rfc-editor.org/info/rfc9068 ↩

3. RFC 9728 OAuth 2.0 Protected Resource Metadata: https://www.rfc-editor.org/info/rfc9728 ↩

4. RFC 9470 OAuth 2.0 Step Up Authentication Challenge Protocol: https://www.rfc-editor.org/info/rfc9470 ↩

5. RFC 6750 The OAuth 2.0 Authorization Framework: Bearer Token Usage: https://www.rfc-editor.org/info/rfc6750 ↩