{"dataset":{"id":"00000000-0000-0000-0000-000000000038","slug":"oauth-best-practices","name":"OAuth 2.0 best practices","description":"Source-linked guidance on OAuth 2.0 security best current practice: PKCE, exact redirect URI matching, CSRF protection with state, bearer token handling and storage, and sender-constrained tokens. Scoped to OAuth 2.0 security per RFC 9700; not a general OAuth tutorial.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Sender-constrained tokens with mTLS and DPoP","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9700#section-4.10.1","text":"A sender-constrained access token is usable only by a specific sender, which must prove knowledge of a secret before a resource server accepts it. The authorization server binds the token to the client, usually with key material known to the client; the resource server performs the proof-of-possession check and prevents replay of the proof. OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (RFC 8705) identifies the client by the fingerprint of its public key: the authorization server obtains the client public key from the TLS stack and associates its fingerprint with the token, and the resource server compares fingerprints the same way. OAuth 2.0 Demonstrating Proof of Possession (DPoP, RFC 9449) is an application-level mechanism using a public/private key pair and application-level signing; it works with public clients and, for confidential clients, combines with any client authentication method. Security is undermined if an attacker obtains both token and key material, for example via cross-site scripting in a browser client; key material held in a security module or TLS stack at least protects the token while the client is offline. Scope: OAuth 2.0 security. Reviewed October 4, 2026.","id":"oauth-best-practices:Sender-constrained tokens with mTLS and DPoP","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Bearer token handling and storage","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9700#section-4.14","text":"Refresh tokens allow short-lived, narrowly scoped access tokens, reducing the impact of access token leakage, but they are an attractive target because they carry the full scope granted to a client. RFC 6749 baseline protection requires confidentiality of refresh tokens in transit and storage, transmission over TLS-protected connections between client and authorization server, a checked binding between each refresh token and its client, and that refresh tokens cannot be generated, modified, or guessed. Issued refresh tokens MUST be bound to the scope and resource servers consented by the resource owner, to prevent privilege escalation and reduce leakage impact. For public clients, authorization servers MUST detect refresh token replay using sender-constrained refresh tokens (RFC 8705 or RFC 9449) or refresh token rotation, where every refresh response issues a new refresh token and invalidates the previous one; a later presentation of an invalidated token reveals the breach and the authorization server revokes the active refresh token. Authorization servers MAY revoke refresh tokens automatically after security events such as a password change or logout, and refresh tokens SHOULD expire after client inactivity. Scope: OAuth 2.0 security. Reviewed October 4, 2026.","id":"oauth-best-practices:Bearer token handling and storage","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"The state parameter and CSRF protection","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9700#section-4.7.1","text":"The long-established CSRF countermeasure is that clients pass a random value, a CSRF token, in the state parameter, linking the request to the redirection URI and the user agent session; RFC 6819 Section 5.3.5 describes this in detail. PKCE or the OpenID Connect nonce value provide the same protection. When using PKCE instead of state or nonce for CSRF protection, clients MUST first ensure the authorization server supports PKCE; if it does not, state or nonce MUST be used. The authorization server MUST provide a way to detect its PKCE support, and publishing RFC 8414 authorization server metadata is RECOMMENDED. If state carries application state and the integrity of its contents matters, clients MUST protect it against tampering and swapping, for example by binding the contents to the browser session or by signing and encrypting state values. PKCE protects robustly even against an attacker who can read the authorization response, whereas an attacker who learns a state value can replay it into a forged authorization response. Preferring PKCE for both injection and CSRF protection in new browser-based clients is Koskamo editorial guidance. Scope: OAuth 2.0 security. Reviewed October 4, 2026.","id":"oauth-best-practices:The state parameter and CSRF protection","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Exact redirect URI matching","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9700#section-4.1.3","text":"Authorization servers MUST compare redirection URIs with exact string matching rather than pattern matching: the two URIs must be equal under the Simple String Comparison of RFC 3986 Section 6.2.1. The only exception is native apps using a localhost URI, where the authorization server MUST allow variable port numbers as described in RFC 8252 Section 7.3. Web servers hosting redirection URIs MUST NOT expose open redirectors. Because browsers reattach URL fragments to a Location redirect only when the Location URL has no fragment of its own, servers MAY attach an arbitrary fragment identifier, for example #_, to URLs in Location headers. Clients SHOULD use the authorization code response type instead of response types that issue access tokens at the authorization endpoint, which enables countermeasures against reuse of leaked credentials and against token replay through sender-constraining. When the origin and integrity of the authorization request can be verified, for example with RFC 9101 or RFC 9126 together with client authentication, the authorization server MAY trust the redirection URI without further checks. Scope: OAuth 2.0 security. Reviewed October 4, 2026.","id":"oauth-best-practices:Exact redirect URI matching","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"PKCE for the authorization code flow","sourceUrl":"https://datatracker.ietf.org/doc/html/rfc9700#section-2.1.1","text":"Clients must prevent authorization code injection and misuse of authorization codes. Public clients MUST use PKCE (RFC 7636); for confidential clients PKCE is RECOMMENDED, because it strongly protects against misuse and injection of authorization codes and, as a side effect, prevents CSRF even in the presence of strong attackers. Confidential OpenID Connect clients MAY instead use the nonce parameter, with additional precautions. The PKCE challenge or nonce MUST be transaction-specific and securely bound to the client and the user agent in which the transaction was started. Although PKCE was designed to protect native apps, this advice applies to all OAuth clients, including web applications. Clients SHOULD use a code challenge method that does not expose the verifier in the authorization request; S256 is currently the only such method. Authorization servers MUST support PKCE, MUST enforce correct use of code_verifier at the token endpoint when a valid code_challenge was sent, and MUST mitigate PKCE downgrade attacks by accepting a token request containing code_verifier only if a code_challenge was present in the authorization request. Publishing code_challenge_methods_supported in RFC 8414 authorization server metadata is RECOMMENDED. Scope: OAuth 2.0 security. Reviewed October 4, 2026.","id":"oauth-best-practices:PKCE for the authorization code flow","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}