OAuth 2.0 integration security: a SaaS implementation guide
Secure SaaS OAuth integrations with authorization code and PKCE, exact redirect matching, least-privilege scopes, validated tokens and a tested revocation path.
In this guide
What does OAuth do, and where do teams get confused?
OAuth 2.0 lets a client obtain limited authorization to access a resource on a user’s behalf. OAuth is an authorization framework; OpenID Connect (OIDC) adds an identity layer for sign-in. If a product only needs delegated API access, do not treat an access token as proof of who the user is. If it needs login, use a correctly implemented OIDC flow and validate the identity token and its claims.
Choose the flow for the client and use authorization code with PKCE
For browser, mobile and other public clients, use the authorization-code flow with Proof Key for Code Exchange (PKCE), using the `S256` challenge method. RFC 9700 also recommends PKCE for confidential clients because it helps prevent code injection and misuse. Use a vetted OAuth/OIDC library and verify that the authorization server enforces the verifier at token exchange.
Keep redirect URIs exact and prevent open redirects
Register each allowed redirect URI and compare it exactly, apart from the limited localhost port exception for native apps described by the standard. Do not accept a redirect target supplied freely by a query parameter or use broad wildcards. An open redirect can send authorization codes or tokens to an attacker-controlled destination.
Request only the scopes the integration needs
List the API actions each integration requires and request the smallest available scope set. Explain the access in plain language before consent, keep read and write privileges separate when the provider supports it and avoid requesting broad scopes for a feature that uses only a narrow endpoint. Reassess scopes when the product changes.
| Client / provider | Redirect URI | Scopes and purpose | Token storage / expiry | Revocation test / owner |
|---|---|---|---|---|
How should a SaaS OAuth client protect authorization responses and tokens?
Bind each sign-in or authorization attempt to the browser session
Use transaction-specific PKCE values and securely associate them with the client and user agent. Keep a one-time `state` value bound to that attempt as a CSRF defense unless the implementation relies on the protections specified for PKCE; for OIDC, use a fresh `nonce` and validate it in the ID token. Do not reuse fixed state, nonce or verifier values.
Validate tokens for the right issuer, audience and purpose
For an OIDC ID token, validate its signature with trusted keys and check issuer, audience, expiry, nonce and other required claims before linking an account. For an access token, use the provider’s documented validation or introspection method and verify the intended resource and permissions. Decoding a JWT is not the same as validating it.
Keep access and refresh tokens out of logs and unsafe storage
Treat bearer tokens as credentials: anyone holding one may be able to use it. Store tokens in a protected server-side secret store where practical, encrypt sensitive records and limit access to the integration worker that needs them. Redact authorization headers, callback query values and token responses from logs and analytics. Rotate client credentials when exposed.
How should SaaS teams manage consent, renewal and revocation?
Use refresh-token protections and short-lived access where supported
Follow the provider’s refresh-token rotation or sender-constraining controls where available, detect reuse if the provider supports it and store the newest token safely. Set a clear response for revoked consent, invalid grants, expiry and provider outages; repeated refresh failures should not create an infinite retry loop.
Provide a clear disconnect and revocation path
Let an account owner disconnect an integration, stop scheduled jobs, delete stored tokens and revoke the grant at the authorization server where the provider supports it. Explain that removing an integration from your product may not erase records already copied into either system. Test the disconnect path and retain only the minimum audit record needed.
Avoid deprecated or unsafe grant patterns
Do not build a new integration around the implicit grant or the Resource Owner Password Credentials grant. RFC 9700 deprecates less secure modes; use a supported authorization-code design and the provider’s current documentation. For service-to-service access without a user, select an appropriately authenticated client-credentials design and narrowly scope the service identity.
OAuth 2.0 integration security questions
Is an OAuth access token the same as an OIDC identity token?
No. An access token authorizes access to a resource and may be opaque. An OIDC ID token carries authentication claims for a client. Validate each token for its intended purpose; do not use an API access token alone to sign a person in.
Is PKCE only for mobile apps?
No. PKCE was first specified for public clients, and RFC 9700 recommends it for confidential clients too. Use `S256`, bind the verifier to the authorization attempt and ensure the server checks it at the token endpoint.
Can one redirect URI handle every customer and environment?
A shared callback can work if it is registered exactly and the client securely binds the response to the correct tenant and authorization attempt. Do not use arbitrary or broadly wildcarded redirect destinations. Separate production and test clients where that reduces configuration and credential risk.
Does deleting a connection in the SaaS app revoke provider access?
Not always. The product should delete or disable its stored credentials and invoke the provider’s revocation endpoint or documented disconnect flow when available. Also account for already-synced data, queued jobs and provider-side grants that the user may need to remove separately.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- IETF RFC 9700: Best Current Practice for OAuth 2.0 SecurityInternet Engineering Task Force
- IETF RFC 7636: Proof Key for Code Exchange by OAuth Public ClientsInternet Engineering Task Force