Notifications
Clear all
Topic starter
22/06/2026 10:10 am
TL;DR: Google sign-in tokens authenticate a user, but they do not automatically authorise access to Calendar, Gmail, or Drive APIs, and SSO users make that separation even more obvious, according to WorkOS. The practical lesson is that login and third-party data access must be governed as distinct identity events, not bundled into one OAuth flow.
NHIMG editorial — based on content published by WorkOS: Your users signed in with Google. That doesn't mean you can call their Google Calendar
Questions worth separating out
Q: How should teams handle Google sign-in and Google API access separately?
A: Treat Google sign-in as authentication only and request Calendar, Gmail, or Drive access in a separate consent step tied to the feature that needs it.
Q: Why do SSO users often break integrations that rely on Google OAuth scopes?
A: SSO authenticates the user through a corporate identity provider, but it does not automatically grant access to Google Workspace APIs.
Q: What do security teams get wrong about OAuth refresh tokens?
A: They often assume a refresh token will keep working after scopes change or that it will be reissued automatically.
Practitioner guidance
- Split sign-in from API consent Keep user login limited to authentication scopes and move Calendar, Gmail, or Drive access into a separate feature-triggered consent flow.
- Review refresh-token assumptions Validate how your integration behaves when refresh tokens are missing, short-lived, or not reissued after scope changes, especially in production-like environments.
- Design for SSO first Test enterprise sign-in paths where the identity provider is Okta, Entra ID, or another SAML source so API access does not depend on Google being the login system.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Exact OAuth scope combinations for Google sign-in versus Calendar, Gmail, and Drive access.
- Implementation pattern for decoupling authentication from data authorisation in an application settings flow.
- Refresh-token edge cases in Google testing mode and why production readiness changes the consent lifecycle.
- How the Pipes connector stores and refreshes tokens when a user reconnects an integration.
👉 Read WorkOS's explanation of Google OAuth sign-in and API access separation →
Google OAuth scopes and SSO: why login tokens fail for APIs?
Explore further
22/06/2026 10:58 am
Authentication and API authorisation are separate governance layers, not interchangeable events. Google OAuth makes the split visible, but many programmes still treat a successful login as if it were also delegated access to data. That assumption fails because an identity assertion says who the user is, while a scope grant says what the application may do. Practitioners should read this as a control boundary problem, not a token-format problem.
A few things that frame the scale:
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
A question worth separating out:
Q: Who is accountable when a user can sign in but still cannot access the required API?
A: The application team is accountable for separating authentication from authorisation, while IAM and security teams are accountable for defining scope policy, consent timing, and revocation handling. If the integration bundles these steps together, failures become hard to diagnose and harder to audit across support, product, and security boundaries.
👉 Read our full editorial: Google OAuth authentication and API access are not the same thing
