Resources · 43
OAuth and OpenID Connect: verify an integration end to end
Separate sign-in, delegation and data permissions, then test redirects, tokens, sessions and revocation.
· 3 min
What this guide helps achieve
- Separate identity from authorisation
- Reject unintended redirects and tokens
- Test denials as carefully as successes
- Verify access removal after departure or incident
Quick check
- Which provider and issuer are expected?
- Is the redirect URI registered precisely?
- Is an ID token wrongly being used as an access token?
- Does each resource check ownership?
- What access survives revocation?
Step-by-step method
- 01
Draw the deployed flow
Identify public or confidential client, browser, authorisation server, API and OIDC provider. Record where codes and tokens travel, who stores them and which roles are granted. A sales diagram does not establish the actual deployment.
Deliverable: flow, trust boundaries and component owners.
- 02
Check the sign-in transaction
Use the code flow with PKCE appropriate to the client. Check S256, transaction binding, registered redirects and protection against forged requests. Test an unexpected URI, incorrect verifier, replayed code and unexpected issuer. RFC 9700 separates requirements and recommendations by client type.
Deliverable: allowed and denied test results.
- 03
Validate the right token
The API validates its access token according to format and provider rules: signature or introspection, issuer, audience, expiry and permissions. The OIDC client separately validates the identity token. A valid signature does not establish that the token belongs to this API.
Deliverable: validation contract and audience and expiry tests.
- 04
Check business permissions
Test an object owned by another account, a lower role, private field and administrative operation. A scope or authenticated gateway does not replace server-side checks on the requested resource. Use authorised test accounts and data.
Deliverable: role, object, operation and expected-denial matrix.
- 05
Exercise expiry and revocation
Separate local session, provider session, access token and refresh token. Test departure, lost device, role change, signing-key rotation and provider outage. Document residual access time instead of assuming that sign-out immediately revokes everything.
Deliverable: access-removal timeline and exceptions.
- 06
Observe without exposing secrets
Log transaction reference, validation decision, error category and configuration version. Exclude codes, tokens and secrets. Prepare diagnosis, integration shutdown and rollback to a validated configuration; replay tests after provider changes.
Deliverable: operating procedure and regression checks.
Worked example
Illustrative situation
Illustrative situation: two clients use one identity provider. A token valid for the first is presented to the second client’s API.
Decision and expected evidence
The API rejects the wrong audience, records a token-free trace and returns no data. The denial becomes a regression test.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| OAuth 2.0 | Delegate resource access | Server-side object permissions |
| OpenID Connect | Establish identity through a validated ID token | Issuer, audience and transaction validation |
| Application session | Maintain application sign-in | Expiry, invalidation and session protection |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Correct denials | Forbidden cases actually blocked | Fix every unexpected acceptance |
| Revocation delay | Time until relevant access disappears | Check sessions and tokens separately |
| Validation failures | Rejections by cause and version | Separate attacks from configuration errors |
Common pitfalls
- Confusing authentication with authorisation
- Accepting any audience after checking the signature
- Registering broad redirect URIs
- Logging tokens for easier debugging
Frequently asked questions
Does PKCE replace every control?
No. It protects the code exchange in the intended flow; token validation, redirects, business authorisation and sessions still need checking.
Is a JWT a permission?
JWT is a format. Claims become usable only after validation and application of your API rules.
Should validation be built from scratch?
Prefer a maintained library and provider documentation, then test your configuration. A correct library can still be configured incorrectly.
Official references
Continue exploring
