Treat RFC 9700, the OAuth 2.0 security best current practice, as your threat list. Draw the client, authorization server and resource server, then check six things: exact redirect URIs, PKCE, no implicit grant, protected refresh tokens, mix-up defense and token audience. Each maps to a known attack.
Draw the three parties
The model needs the client app, the authorization server that signs the user in, and the resource server that accepts tokens. Trust boundaries sit between each pair. The browser redirect between client and authorization server is the weakest hop, because tokens and codes travel through a place an attacker may watch.
The checks, in plain words
| Check | What RFC 9700 says | Threat it addresses |
|---|---|---|
| Redirect URIs | Use exact string matching, except port numbers for native app localhost redirects | Code or token sent to an attacker's URL |
| PKCE | Public clients must use it; confidential clients should; recommended method is S256 | Stolen authorization codes being redeemed |
| Implicit grant | Avoid response types that return access tokens from the authorization endpoint; use the authorization code flow | Tokens exposed in URLs |
| Refresh tokens | For public clients, sender-constrain them or use rotation | Long lived token theft |
| Mix-up | Clients using several authorization servers must defend; check the iss parameter per RFC 9207 | Client confused about which server issued a response |
| Audience | Restrict access tokens to specific resource servers; resource servers must reject tokens not meant for them | A token for one API replayed at another |
Section numbers in the RFC for these include 2.1, 2.1.1, 2.1.2, 2.2.2 and 2.3, with the attack descriptions in section 4.
Turn the table into your model
- List which clients are public and which are confidential.
- For each, mark the flow in use. If any use the implicit grant, mark it as a finding.
- Check how redirect URIs are registered and compared.
- Check whether the authorization server enforces PKCE verification.
- Decide how refresh tokens are rotated or bound.
- Check each API for audience validation.
Common model gaps
- Writing "uses OAuth" in the diagram and stopping there.
- Not noticing the app talks to more than one authorization server.
- Forgetting that resource servers must check where a token was meant to be used.
I read the first 100,000 characters of the RFC for this post. Check the full text for details such as dates and further attack sections before you rely on a specific clause.
Try it yourself
Click through it at your own pace, or open it full screen. Click through it and look at how the libraries behind your sign in code show up in a dependency inventory.
Quick check
Is PKCE only for mobile and single page apps?
No. RFC 9700 says public clients must use it and confidential clients should too. Authorization servers must support it and enforce the verifier check when a challenge was sent.
Why check the audience of a token?
Without it, a token issued for one resource server can be replayed at another. The RFC says resource servers must reject tokens that were not meant for them.
A note on tooling
Safeguard covers the libraries behind your sign in code with SBOM and dependency scanning and reachability analysis. Try the free scan.
Sources
Last reviewed: 19 October 2026.
