What matters first
- Choose a supported authorization flow and use PKCE as appropriate to current guidance.
- Treat redirect handling and account linking as security-sensitive decisions.
- Review granted scope and token acceptance at the downstream service.
Map the parties and intended authority
Identify the client, authorization server, identity provider, resource server, and user involved in each integration. Record whether the purpose is user sign-in, delegated API access, or a machine-to-machine operation. Confusing these purposes makes token and permission decisions harder to review.
List redirect URIs, supported clients, token audiences, granted scopes, and account-linking rules. Include mobile and preview deployments where they use different registration settings. The same provider can be configured securely for one client and too broadly for another.
Review flow and redirect protection
Use a supported flow and the provider’s current security recommendations, including authorization-code protection with PKCE where applicable. Review request binding, redirect matching, and handling of state and nonce according to the protocol and client library in use. Do not replace library validation with assumptions based on the UI flow.
Check error and cancellation paths as well as a successful sign-in. An integration should not accept a callback intended for another session, treat an arbitrary redirect as trusted, or expose tokens through unnecessary logs and browser-visible locations. Use controlled accounts and provider test environments for validation.
Validate tokens and account relationships
A receiving application needs to verify the token type and claims it actually relies on. Review the expected issuer, audience, signing keys, timing, and subject mapping. An ID token intended for a client should not automatically become a credential accepted by a separate API.
Account linking deserves its own product rule. Decide how the application establishes that an external identity may be attached to an existing account and how unlinking or organization membership removal affects access. A matching display name is not a reliable identity relationship.
Constrain delegated permissions and lifecycle
Request only the provider scopes needed for the workflow. Review where refresh credentials are stored, how access is revoked, and what happens when the user disconnects an integration. Make sure background jobs do not retain broader access than the user expects after a connection changes.
Verify the legitimate integration after permission reduction and key rotation. Preserve tests for rejected callbacks and incorrect token audiences. Good security review includes operational behavior: a provider outage should lead to a controlled failure rather than a shortcut that skips validation.
Your next steps
- Inventory clients, providers, redirects, scopes, and token consumers.
- Compare each integration with current provider and protocol guidance.
- Test account linking, revocation, failure paths, and wrong-recipient tokens.
- Discuss the sensitive identity transitions your application needs reviewed.
Questions teams ask
Are OAuth and OIDC the same thing?
OAuth concerns delegated authorization. OpenID Connect adds an identity layer for authentication. An integration may use both, but their token purposes should remain clear.
Should we build custom token validation?
Prefer a maintained integration library with explicit configuration and provider guidance. Review its behavior rather than reimplementing protocol checks casually.
Sources and editorial notes
Public-source facts are cited above. The review questions and action plans are Cyphen’s guidance for applying those lessons to your own systems. Sources checked on .