Information Security 12 min read

Understanding OAuth2.0: Principles, Architecture, and Implementation

This article explains the OAuth2.0 authorization protocol, distinguishes it from single sign‑on, describes its core entities and step‑by‑step flow, and outlines how web servers, user agents, and native applications interact to securely obtain access tokens for protected resources.

Top Architect
Top Architect
Top Architect
Understanding OAuth2.0: Principles, Architecture, and Implementation

When the author first encountered OAuth2.0, it was often confused with SSO; after implementing an SSO system, they clarified the differences and decided to write a comprehensive tutorial on OAuth2.0.

OAuth2.0 is an open authorization protocol that enables a third‑party application to access a user's resources without requiring the user's credentials, by granting limited permissions.

The typical scenario involves a user who has a WeChat account, a third‑party website that wants to read the user's friends and chat data, and the need to grant this access securely through OAuth2.0 rather than sharing passwords.

Four main entities participate in the OAuth2.0 flow: the resource owner (user), the client application (third‑party), the authorization server, and the resource server.

The standard flow consists of nine steps: (1) the user initiates access via a client (e.g., Google or WeChat); (2) the client redirects the user to the authorization server with its client ID and secret; (3) the user authenticates and authorizes; (4) the client logs in; (5) the authorization server issues an authorization code and redirects to the client’s redirect URI; (6) the client receives the code; (7) the client exchanges the code, client ID, and secret for an access token; (8) the authorization server returns the access token; (9) the client uses the token to request the protected resource.

Key OAuth2.0 terminology is defined: authentication, federated authentication, authorization, delegated authorization, and the specific roles of resource owner, client, resource server, and authorization server.

In a web‑server deployment, the client ID and secret are stored on the server to keep them confidential, while the resource server hosts the protected APIs.

User agents (e.g., browser‑based JavaScript) act as the client side of the flow, and native applications (desktop or mobile) can also act as clients, storing credentials locally.

The article concludes that understanding the OAuth2.0 flow and its related HTTP concepts is essential for securely obtaining access tokens and integrating with third‑party services.

backend developmentAuthenticationWeb SecurityauthorizationSSOOAuth2.0
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.