OAuth
OAuth is an authorisation framework that lets one application obtain limited access to a service on a user's behalf, through a token scoped to specific actions, so the application never has to see or store the user's password for that service.
Submit a project See the MCP server integration guideReviewed by Huy Nguyen (David), CEO · Updated 30 Oct 2026 · 5 min read
This term is one of the entries in the OutsourcingVN glossary of words buyers meet while scoping an integration or an AI agent that must reach into another system.
Why does OAuth matter?
The IETF standard, RFC 6749, states the framework's purpose plainly: "The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf." The access it grants is a token, not a copy of a password: RFC 6749 defines an access token as "a string representing an authorization issued to the client," and that string can carry a scope, a request parameter the client uses "to specify the scope of the access request." OutsourcingVN is operated by Netbase JSC, and the reason a buyer should care how an integration authenticates is that a scoped, revocable token limits what a compromised integration can reach, while a shared password does not.
What is an example of OAuth in practice?
An AI assistant needs to read a user's calendar to suggest meeting times. Instead of asking for the user's email password, the assistant redirects the user to the calendar provider, the user approves a request limited to reading calendar events, and the provider hands the assistant a token scoped to that one permission. The assistant calls the calendar's API with that token; it never learns the user's password, and the user can revoke the token later without changing any password at all.
What are the common misreadings of OAuth?
OAuth is not the same as authentication: RFC 6749 defines an authorization framework for granting access to a resource, and the OpenID Foundation's own specification is explicit that identity is a separate, additional layer: "OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol," built specifically to let an application also verify who the user is, which plain OAuth does not do by itself. OAuth is also not single sign-on: single sign-on lets a user log in once across multiple applications, which is a pattern commonly built using OpenID Connect's identity layer, not a feature OAuth itself defines. And an API key is not an OAuth access token: an API key is typically a long-lived, often unscoped credential issued directly to a developer, where an OAuth access token is scoped, tied to a specific grant, and designed to be issued through the authorisation flow RFC 6749 describes rather than copied into code by hand.
Plan the next step for your project
Common questions
RFC 6749 lets the client "specify the scope of the access request" so that a token grants only the narrow permission requested, such as reading calendar events, rather than full access to the account.
No. RFC 6749 governs access to a resource, not identity; the OpenID Foundation built OpenID Connect specifically as "an identity layer on top of the OAuth 2.0 protocol" for that purpose.
It is the same family, cited as an IETF draft rather than a final standard: the Model Context Protocol's 2025-06-18 authorization specification bases its flow on the "OAuth 2.1 IETF DRAFT," naming the MCP server an "OAuth 2.1 resource server" and the MCP client an "OAuth 2.1 client."
Not by design: RFC 6749 says tokens "represent specific scopes and durations of access, granted by the resource owner," and lets the authorization server state a token's lifetime when it issues it, which is a large part of why a scoped token is safer to grant than a shared password.
Which decisions does OAuth affect?
Whether an AI agent reaches a system through a scoped token or a shared credential is central to the AI agent tool permissions guide's decision about what an agent may do and when a person must confirm an action, and the MCP server integration guide covers building a server whose authorisation specification is built on OAuth 2.1 for HTTP transports. The Model Context Protocol entry defines the wider standard that authorisation step belongs to, and an AI agent is the kind of caller a scoped token is usually written for. When you know which system an integration or an agent needs scoped access to, describe it and Netbase will respond through Netbase's own outsourcing-services platform; submit a project when you are ready.