Use the authorization code grant with PKCE for every client type, drop the implicit flow, request the minimum scopes, and rotate refresh tokens. These defaults come from OWASP's OAuth 2 guidance and close the most common ways a stolen code or token turns into account access.
Use authorization code with PKCE
OWASP says clients must use the Authorization Code Grant with PKCE for all client types, including single-page and native apps. PKCE ensures an attacker cannot redeem a stolen authorization code without the code verifier. Authorization servers must support it, and should reject a token request carrying a code verifier when the original request had no code challenge.
Retire the implicit flow
The implicit grant is deprecated and should not be used. It returns tokens in the URL fragment, where browser history and scripts on the page can reach them.
Keep scopes small
Limit access token privileges to the minimum the application needs. Ask for narrow scopes at first and request more when a feature needs them. Wide scopes also make consent phishing more rewarding for an attacker, so review the third-party apps authorised in your own tenant.
State and redirects
Use a one-time CSRF value in the state parameter, bound to the user agent, unless PKCE or an OpenID Connect nonce already protects the flow. Neither clients nor authorization servers may act as open redirectors, and authorization servers must not accept http redirect URIs, except loopback redirects for native clients.
Token lifetime and refresh rotation
Short-lived access tokens limit exposure. OWASP gives no specific lifetimes, so set them from your risk. For refresh tokens, rotation means issuing a new one and immediately invalidating the old, so a replay of a stolen refresh token is detected. OWASP recommends rotation, alone or with sender-constrained tokens using DPoP or mTLS.
A review checklist
- Which flow does each client use? Any implicit?
- Is PKCE enforced server side?
- List the scopes per client and trim.
- Are redirect URIs exact and registered?
- Do refresh tokens rotate, and is replay logged?
- Where does each client store tokens? See session timeouts and logout for why browser storage is risky.
For SSO choices, see SAML vs OIDC.
Keep an inventory of the OAuth clients and third-party apps connected to your own systems. Each one is a standing grant that may hold wide scopes long after anyone remembers why it was approved. Review the list on a schedule, remove the unused, and require an owner for each. This is the same hygiene as removing stale service accounts, applied to delegated access.
Quick check
Do confidential clients need PKCE?
OWASP says authorization code with PKCE for all client types, so yes.
Is a long access token lifetime ever fine?
OWASP says long-lived tokens warrant extra protection such as sender-constraining. Prefer short ones.
Sources
Last reviewed: 19 October 2026.
