Domů Procházet Nápověda
Registrovat se Přihlásit se
efren
/
testing-proxy
1
0
Rozštěpit 0
Soubory Úkoly 0 Pull Requesty 0 Wiki
Strom: bfc057bbd4
Větve Značky
testing-proxy
/
docs
/
SYNTHESIS-OAUTH-2.1.md

SYNTHESIS-OAUTH-2.1.md 11 KB
Historie Surový

Ultraresearch Synthesis: OAuth 2.1 Authorization Server Metadata & Security Requirements

Workers: 8 parallel web searches + 4 document fetches Waves: 2 (initial saturation + targeted section extraction) Sources: 6 primary (RFC 8414, draft-ietf-oauth-v2-1-15, RFC 9700, RFC 9126, RFC 8705, RFC 7662) Verifications: Cross-referenced across RFC 8414 txt, OAuth 2.1 draft HTML/txt/markdown, RFC 9700 txt

Executive Summary

OAuth 2.1 (draft-ietf-oauth-v2-1-15, March 2026) consolidates RFC 6749, RFC 6750, RFC 8252, RFC 9700, and browser-based-app best practices into a single standards-track specification. It makes previously optional security extensions—especially PKCE—mandatory, removes insecure grant types (Implicit, Resource Owner Password Credentials), and mandates exact redirect URI matching. RFC 8414 defines the authorization server metadata format and registry; OAuth 2.1 references it as the discovery mechanism but does not redefine its fields. RFC 9700 (Security BCP) provides the threat model and mitigation requirements that OAuth 2.1 normatively incorporates.

1. REQUIRED Fields (RFC 8414 Section 2)

Per RFC 8414, the following metadata values are REQUIRED in the oauth-authorization-server metadata response:

  • issuer — The authorization server's issuer identifier. MUST be an https URL with no query or fragment components. MUST exactly match the URL used to fetch the metadata (Section 3.3).
  • authorization_endpoint — URL of the authorization endpoint. REQUIRED unless no grant types are supported that use the authorization endpoint.
  • token_endpoint — URL of the token endpoint. REQUIRED unless only the implicit grant type is supported.
  • response_types_supported — JSON array of supported OAuth 2.0 response_type values (e.g., ["code"]).

2. RECOMMENDED / SECURITY-CRITICAL Fields

The following are not strictly REQUIRED by RFC 8414 but are strongly RECOMMENDED for a secure OAuth 2.1 deployment:

  • scopes_supported — RECOMMENDED. JSON array of supported scope values.
  • jwks_uri — OPTIONAL but highly RECOMMENDED. URL of the JWK Set document (MUST use https). Required for clients to validate server signatures and for asymmetric client auth.
  • code_challenge_methods_supported — OPTIONAL in RFC 8414, but OAuth 2.1 makes PKCE mandatory. Therefore, publishing this field (containing at least ["S256"]) is RECOMMENDED so clients can detect PKCE support (RFC 9700 Section 2.1.1; OAuth 2.1 Section 4.1.1).
  • grant_types_supported — OPTIONAL (defaults to ["authorization_code", "implicit"]). In OAuth 2.1, should reflect only supported grants (e.g., ["authorization_code", "client_credentials", "refresh_token"]). Note: OAuth 2.1 removes implicit, so the default is misleading for pure 2.1 servers.
  • token_endpoint_auth_methods_supported — OPTIONAL (defaults to ["client_secret_basic"]). For highest security, servers SHOULD advertise asymmetric methods such as private_key_jwt and tls_client_auth (RFC 9700 Section 2.5).
  • token_endpoint_auth_signing_alg_values_supported — OPTIONAL, but MUST be present if private_key_jwt or client_secret_jwt is advertised. SHOULD support RS256; none MUST NOT be used.
  • revocation_endpoint / revocation_endpoint_auth_methods_supported / revocation_endpoint_auth_signing_alg_values_supported — OPTIONAL. If revocation is supported, auth method metadata follows the same rules as the token endpoint.
  • introspection_endpoint / introspection_endpoint_auth_methods_supported / introspection_endpoint_auth_signing_alg_values_supported — OPTIONAL. RFC 9701 (JWT Response for Token Introspection) and RFC 7662 require authenticated callers; metadata should reflect supported auth methods.
  • pushed_authorization_request_endpoint — Defined by RFC 9126 (PAR). RECOMMENDED for highest security to prevent request tampering and large-URI issues.
  • require_pushed_authorization_requests — Boolean (RFC 9126). If true, the AS accepts authorization request data only via PAR.

3. Security Requirements Mandatory in OAuth 2.1

3.1 PKCE (Proof Key for Code Exchange)

  • Authorization servers MUST support code_challenge and code_verifier (OAuth 2.1 Section 4.1.1).
  • Clients MUST use PKCE for all authorization code flows, and authorization servers MUST enforce their use except under conditions described in Section 7.5.1 (authorization code injection). Even then, enforcing PKCE is still RECOMMENDED.
  • S256 is Mandatory To Implement (MTI) on the server. Clients capable of using S256 MUST use it. plain is permitted only if the client cannot support S256 for technical reasons and knows the server supports plain (via metadata or out-of-band).
  • The AS MUST mitigate PKCE downgrade attacks: a token request containing code_verifier must be accepted only if code_challenge was present in the authorization request (RFC 9700 Section 2.1.1; OAuth 2.1 Section 7.5).

3.2 Removed / Deprecated Features

  • Implicit grant (response_type=token) is omitted from OAuth 2.1 (Section 10.1). Servers should not support it; clients must not use it.
  • Resource Owner Password Credentials grant is omitted from OAuth 2.1 (RFC 9700 Section 2.4; incorporated into OAuth 2.1). MUST NOT be used.

3.3 Redirect URI Handling

  • Exact string matching is REQUIRED when comparing redirect URIs (OAuth 2.1 Section 2.3.1; RFC 9700 Section 2.1). The only exception is for localhost loopback URIs of native apps, where the port may vary (Section 8.4.2).
  • The redirect_uri parameter in the token request is now REQUIRED if the redirect_uri was included in the authorization request (OAuth 2.1 Section 10.2). This closes a loophole where attackers could swap redirect URIs during code exchange.
  • Authorization servers MUST require registration of the complete redirect URI including the path (OAuth 2.1 Section 2.3.1).

3.4 Refresh Token Security

  • For public clients, refresh tokens MUST be either sender-constrained (e.g., DPoP, mTLS) or use refresh token rotation (one-time use) (OAuth 2.1 Section 4.3.3; RFC 9700 Section 2.2.2).
  • If refresh tokens are issued, they MUST be bound to the scope and resource servers as consented by the resource owner (OAuth 2.1 Section 4.3.3).

3.5 Bearer Token Transmission

  • Bearer tokens MUST NOT be passed in the query string of URIs (OAuth 2.1 Section 5.1). Only Authorization header or form-encoded body parameter are permitted.

3.6 Transport Security

  • TLS is mandatory for all OAuth protocol URLs (must use https) except native-app loopback redirects (OAuth 2.1 Section 1.5).
  • TLS certificates MUST be checked per RFC 9110 Section 4.3.4.
  • TLS 1.3 (RFC 8446) is the most recent version at time of writing; TLS 1.2 is the minimum generally accepted.

3.7 Client Authentication

  • It is RECOMMENDED to use asymmetric cryptography for client authentication, such as:
    • Mutual TLS (tls_client_auth) — RFC 8705
    • Private Key JWT (private_key_jwt) — RFC 7521 / RFC 7523
  • When asymmetric methods are used, the AS does not need to store sensitive symmetric keys, reducing leakage risk (RFC 9700 Section 2.5).

3.8 Sender-Constrained Access Tokens

  • Authorization and resource servers SHOULD use sender-constraining mechanisms such as DPoP (RFC 9449) or mTLS (RFC 8705) to prevent misuse of stolen tokens (OAuth 2.1 Section 1.4.3; RFC 9700 Section 2.2.1).

3.9 Authorization Server Mix-Up Mitigation

  • When a client interacts with multiple ASes, a defense against mix-up attacks is REQUIRED. The iss parameter in the authorization response (RFC 9207) SHOULD be used (RFC 9700 Section 2.1; OAuth 2.1 Section 7.15).

4. Complete Set of Endpoints and Auth Methods (OAuth 2.1 Best Practices)

Endpoint Specification Client Auth Method Notes
Authorization Endpoint OAuth 2.1 Section 3.1 None (user-agent facing) MUST NOT support CORS. MUST use exact redirect URI matching.
Token Endpoint OAuth 2.1 Section 3.2 client_secret_basic (default), client_secret_post, private_key_jwt, tls_client_auth, none for public clients Asymmetric auth RECOMMENDED.
Token Introspection RFC 7662 Any token-endpoint auth method, or a dedicated RS access token RFC 9701 mandates authenticated callers; MUST NOT allow unauthenticated introspection.
Token Revocation RFC 7009 Same as token endpoint (client_secret_basic default)
Pushed Authorization Request (PAR) RFC 9126 Same as token endpoint RECOMMENDED. Returns request_uri used at authorization endpoint.
Device Authorization RFC 8628 Client auth at device endpoint For input-constrained devices.
Dynamic Client Registration RFC 7591 Varies (often initial access token or reg access token)
JWKS URI RFC 8414 None (public keys) Used by clients to fetch AS signing keys.

5. Differences Between OAuth 2.0 and OAuth 2.1 Affecting Implementation

Feature OAuth 2.0 (RFC 6749) OAuth 2.1 (draft-15)
PKCE Optional (RFC 7636 extension) Mandatory for all authorization code flows
Implicit Grant Supported Removed / Omitted
Password Grant (ROPC) Supported Removed / Omitted
Redirect URI Matching Flexible (prefix, wildcard, pattern matching common) Exact string matching required (except localhost port)
Redirect URI in Token Request Not required Required if present in auth request
Bearer Token in Query String Allowed Prohibited
Refresh Tokens (Public Clients) No special constraints Must be sender-constrained or rotated
Client Types Complex definitions (confidential/public based on ability to maintain cred secrecy) Simplified: based on whether client has credentials
S256 Optional PKCE method Mandatory To Implement

Sources (Primary)

  1. RFC 8414 — OAuth 2.0 Authorization Server Metadata (June 2018) — https://www.rfc-editor.org/rfc/rfc8414.txt
  2. draft-ietf-oauth-v2-1-15 — The OAuth 2.1 Authorization Framework (March 2026) — https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-15.txt
  3. RFC 9700 — Best Current Practice for OAuth 2.0 Security (January 2025) — https://www.rfc-editor.org/rfc/rfc9700.txt
  4. RFC 9126 — OAuth 2.0 Pushed Authorization Requests — https://datatracker.ietf.org/doc/rfc9126/
  5. RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
  6. RFC 7662 — OAuth 2.0 Token Introspection
  7. RFC 9701 — JSON Web Token (JWT) Response for OAuth Token Introspection