Loading content
OAuth 2.0 allows applications to access users' resources without exposing their credentials. It is a flexible and secure method employed in many modern web applications.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Technical building block: can be automated, integrated, or operated.
Concrete cog in the system that works inside larger relationships.
OAuth 2.0 is an authorization standard for delegated access via tokens: a client obtains permissions from an authorization server and uses the resulting tokens to call protected resources on a resource server.
OAuth 2.0 was standardized as a common framework for authorization in modern application scenarios and developed in the IETF’s OAuth Working Group. Its formal foundation is the publication RFC 6749 (“OAuth 2.0 Authorization Framework”), which defines the core concepts and enables multiple authorization-flow variants (covering web, desktop, mobile, and device-like clients). The motivating problem is delegating access to users’ resources without requiring clients to expose user credentials; the standard achieves this through defined roles, grants, and token lifecycles.
See OAuth 2.0 as a “permission chain with token handoff”: first, the client initiates authorization (client → authorization server). Next, the authorization outcome is turned into tokens (grant → token endpoint exchange). Then, the client can act on the resource server only with tokens that the resource server accepts. When an access token expires, the chosen flow determines whether the client can proceed via a refresh-style path (e.g., using refresh tokens) or must go back to the authorization server for re-authorization.
The application that requests authorization and presents tokens as credentials when calling the resource server.
The component that coordinates authorization decisions, issues grants, and provides tokens at the token endpoint (including appropriate client authentication depending on the flow).
The API/resources component that validates presented tokens and allows or denies protected operations.
OAuth 2.0 separates authorization from token issuance: only after the grant-to-token exchange can the client call the resource server.
Scopes define which resources and operations a token should permit, translating consent/authorization decisions into token-held permissions.
The concrete flow variant determines how authorization is initiated, how the grant is obtained, and how tokens are exchanged.
OAuth 2.0 is useful when you need delegated API access without tightly coupling the resource server to the client’s user-login handling—especially when choosing an appropriate authorization flow, designing scopes, and managing the token lifecycle (refresh vs. re-authorization). Limits/trade-offs: OAuth 2.0 is primarily about authorization, not a complete identity/login solution—authentication scenarios commonly require an additional identity protocol. Also, the idea that credentials are never exposed is not universal: the specification set includes “Legacy: Password Grant,” meaning credential-handling can occur in specific (legacy) choices.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.