Key takeaways
- OAuth delegates limited access to resources without giving the client the user’s account password.
- Authorization, user identity and approval of a specific action are separate concerns.
- Scopes, token storage, revocation and workspace binding need explicit implementation.
Overview
OAuth describes delegated authorization, not a complete user-identity protocol by itself. A flow issues tokens with defined permissions and lifetimes. Applications must protect tokens, request appropriate scopes and handle expiration and revocation. The correct flow and security requirements depend on the client type and provider’s current implementation guidance.
How it works
Request only the permissions needed for the integration’s purpose.
Complete the provider-supported authorization flow and store tokens securely.
Use scoped access, refresh when permitted and honor revocation or disconnection.
Understand who grants access to what
A user connecting a CRM is authorizing an application to access resources through the provider’s supported flow. The resulting token has a scope and lifecycle; it is not the user’s password. The client must understand which account and resources the token represents before attaching the connection to a workspace.
OAuth itself addresses authorization. Authentication protocols such as OpenID Connect add identity semantics for sign-in. A product can use both, but an arbitrary access token should not be treated as proof of every identity claim. Use the provider’s documented flow and current security guidance; RFC 9700 updates OAuth 2.0 security practice beyond the original framework.
| Concern | Question | Evidence or control |
|---|---|---|
| Identity | Which user and provider account are connecting? | Validated provider identity information |
| Authorization | Which resources and operations are allowed? | Granted scopes and resource permissions |
| Workspace binding | Which local tenant owns the connection? | Authenticated local session and ownership checks |
| Task approval | Is this particular write or export intended? | Application action rules and user authorization |
Source material: IETF / RFC Editor — RFC 6749: OAuth 2.0 authorization framework ↓ · IETF / RFC Editor — RFC 9700: Best current practice for OAuth 2.0 security ↓
Treat tokens as a managed credential lifecycle
Store tokens on appropriate trusted infrastructure, restrict access and keep them out of URLs, browser bundles and routine logs. Request only the scopes needed for the integration. A future feature that might need broader access is not a reason to grant every available permission today.
Handle expiry, refresh and revocation according to the provider’s contract. Refresh-token behavior can involve rotation and concurrency concerns, so two workers should not blindly race to replace the same credential. A disconnected integration should stop scheduled operations and clearly show which work needs a new authorized connection.
Test account switching and interrupted consent
An illustrative user starts connecting a CRM in workspace A, changes local workspaces in another tab and then completes the provider flow. The callback must bind the result to the intended, validated connection context rather than whichever workspace happens to be visible afterward. Similar care is needed for canceled consent and repeated callbacks.
Test insufficient scopes, revoked access, expired tokens and a user who lacks authority to connect the provider account. Surface a recoverable reconnect state without leaking credential details. A successful authorization redirect is only the beginning; verify that subsequent operations are restricted to the correct resources and stop when access is withdrawn.
What this looks like in practice
A user connects a CRM and grants access to selected objects. The integration uses the resulting authorization to update approved records; it does not receive the user’s CRM password.
Examples explain the concept; they are not reported customer results.What to check
Review scopes, redirect validation, token storage and disconnect behavior. Confirm that one workspace cannot use another workspace’s connection.
Common mistake
Requesting every available scope for convenience or continuing background work after a user has revoked the integration’s access.
OAuth vs. Model Context Protocol
OAuth controls delegated access. MCP defines an interface for AI applications to use tools and resources. An MCP connection may use OAuth, but the two solve different problems.
Read the Model Context Protocol definition →Questions answered
What is OAuth?
OAuth is an authorization framework that lets an application obtain limited access to resources on behalf of a user or another authorized party without requiring the application to collect that party’s password.
Is OAuth the same as signing in?
Not by itself. Identity protocols such as OpenID Connect build on OAuth for authentication. Read the provider’s contract to understand what a token establishes.
Does granting OAuth access approve every action?
No. A token defines technical access. The application must still respect the user’s task, workspace permissions and any required approval for consequential actions.
Does OAuth consent authorize every future action?
No. It grants technical access within defined permissions, while the application still needs to respect the user’s task, local roles and action policies. A token that can write CRM records does not make every possible write appropriate. Keep access scope and specific action authorization separate.
Should an integration ask users for their provider password?
Use the provider’s supported authorization flow rather than collecting the user’s account password for a delegated integration. Current OAuth security guidance also changes which flows are appropriate. Follow the provider and current standards instead of reproducing an outdated example from an old tutorial.
References and further reading
Primary documentation and source material for this topic. Sources checked September 14, 2026; provider requirements can change.
- RFC 6749: OAuth 2.0 authorization framework ↗IETF / RFC Editor
- What is the Model Context Protocol? ↗Model Context Protocol
- RFC 9700: Best current practice for OAuth 2.0 security ↗IETF / RFC Editor
Continue reading on the blog
Explore all articles and guides →Put the concept to work.
Explore the relevant AstroFabric workflow and see how the pieces connect.
Help keep this guide useful. Suggest a correction or browse the full glossary.