OAuth 2.1 consolidates OAuth 2.0 with later security guidance and removes older grant choices. As checked on 12 November 2026, draft 17 remains an Internet-Draft. Use its exact version when evaluating conformance claims.

For an existing application, start with your actual flows. Review PKCE, redirect matching, token handling and refresh protection. A provider's “OAuth 2.1” label does not establish how your particular client is configured.

Separate the working draft from final guidance

The OAuth 2.1 draft 17 is the current draft used for this review. It is not an issued RFC. RFC 9700 is published OAuth 2.0 security best current practice.

These documents have related purposes but different status. Maintain the source and version beside each architecture decision. Review later revisions deliberately rather than treating a draft number as permanent.

Area	Older integration to inspect	Current design direction
Authorization grant	Implicit or password flow	Authorization code with PKCE where appropriate
Redirect URI	Wildcard or prefix acceptance	Exact registered matching, with the specified exceptions
Refresh token	Long-lived reusable bearer credential	Rotation or applicable sender constraint
Token audience	One broadly accepted token	Explicit recipient and validation rules
Client authentication	Assumed interchangeable methods	Registered method supported by the actual server

OAuth authorizes access. OpenID Connect adds an authentication layer. Keep the ID token and access token roles distinct when implementing login.

Use PKCE for the authorization-code exchange

PKCE binds an authorization request to a verifier held by the initiating client. The client sends an S256 challenge initially. It supplies the corresponding verifier at the token endpoint. PKCE specification.

Under RFC 9700, public clients must use PKCE and confidential clients should use it. The OAuth 2.1 draft makes it part of the authorization-code flow. NamoID currently requires S256 for public and confidential authorization-code clients.

Use the runnable S256 example to test encoding against the RFC's known vector. The verifier length is 43–128 permitted characters. The unpadded S256 challenge has 43 characters.

Authorization request: challenge + S256 + registered redirect
Token request: code + matching verifier + required client authentication

A client secret does not replace the verifier. Keep the verifier out of URLs, analytics and support messages. The PKCE guide explains failure cases and the complete exchange.

Replace removed grants with a suitable flow

The draft removes the implicit and resource-owner-password grants. Do not replace an old password flow by sending the same credentials through an undocumented endpoint.

For browser applications, review the backend and session boundary. For native applications, use the appropriate external authorization journey and registered redirect behavior. The right architecture depends on the client and the resource.

Use the browser application guide and BFF versus SPA comparison for those decisions. An old flow can require application changes beyond switching a grant name.

Match redirects and prevent request confusion

Register the intended redirect URI and apply the specification's matching rules. Review any loopback exception only in its defined context. Avoid general wildcard rules and open redirects.

Bind the returned response to the initiating transaction. With multiple authorization servers, ensure the client identifies the intended issuer. Exact redirect matching, issuer and mix-up defenses.

Test an altered redirect, mismatched issuer, reused code and wrong verifier. Record the failure stage without recording live credentials.

Review refresh tokens and existing sessions

Refresh-token rotation detects particular reuse patterns. It does not make an already stolen access token disappear. Sender-constrained tokens also require the resource to enforce the binding.

Use the refresh rotation test guide for concurrency and retry cases. Use the logout review to identify sessions that remain active after an action.

Build a migration checklist for each client

Inventory grants, redirects and client-authentication methods.
Record the applicable source and draft version.
Test S256 and the required token request.
Reject altered redirects and mismatched transactions.
Validate tokens at the receiving resource.
Test refresh failure and session termination.
Rehearse the change with synthetic accounts.
Record rollback and the remaining client dependencies.

Use the RFC 9700 checklist for a broader review. The first-party login guide covers client ownership. Framework examples are available for Next.js and React.

Review the integration with NamoID

NamoID engineers can help inspect issuer configuration, PKCE and application token validation. Bring the flow and a synthetic failure example rather than a live token.

Share your client type, stack and intended resource in Slack for an early response. Contact the NamoID team