Understanding OAuth2.0: Principles, Architecture, and Implementation

The author, a senior architect, shares a comprehensive tutorial on OAuth2.0 after previously mixing it up with single sign‑on (SSO). The goal is to clarify the protocol’s principles and provide practical guidance for integrating it with e‑commerce platforms.

What is OAuth2.0

OAuth is an open authorization protocol that enables a user to grant a third‑party application limited access to resources stored on another site without sharing credentials.

To illustrate the concept, the article uses a scenario where a user registers on WeChat, adds friends, and wants a third‑party website to analyze chat data without handing over the WeChat password.

The solution is OAuth2.0: the user authorizes the website to obtain specific permissions, and can later revoke them.

A complete OAuth2.0 flow involves three entities:

Resource Owner (e.g., the user)

Client Application (the third‑party website or app)

Authorization Server / Resource Server (e.g., WeChat, Google, Facebook)

OAuth2.0 Architecture

The typical flow consists of nine steps:

The user accesses a resource using a third‑party app (e.g., Google, WeChat).

The client redirects the user to the authorization server with its client ID and secret.

The user sees the authorization screen and grants permission.

The client authenticates using its unique client ID and secret.

The authorization server redirects the user back to the client’s redirect URI with an authorization code.

The client receives the code via the redirect URI.

The client sends the code, client ID, and secret to the authorization server.

The authorization server returns an access token to the client.

The client uses the access token to call the resource server on behalf of the user.

This process relies on underlying HTTP concepts.

Key Terminology

Authentication

Identifying a user, typically via username and password.

Federated Identity

Allows multiple systems to share a single authentication mechanism.

Authorization

Granting permission to perform an action after authentication.

Delegated Authorization

Giving another party the right to act on your behalf.

Roles

OAuth defines four roles:

Resource Owner – the entity that can grant access to its data.

Client Application – the app that requests protected resources on behalf of the owner.

Resource Server – the API server that hosts the protected resources.

Authorization Server – issues access tokens after obtaining permission from the resource owner.

Web Server Scenario

A web server uses HTTP to deliver pages and stores the client ID and secret securely to request resources from the resource server.

User‑Agent Application

A user‑agent (e.g., a browser‑based JavaScript app) interacts with the web server and the authorization server to obtain an access token.

Native Application Scenario

Native apps (desktop or mobile) embed the client ID and secret in the application code and follow a similar flow, but the credentials are stored on the device.

Conclusion

The article recaps the OAuth2.0 workflow, clarifies related terminology, and emphasizes the importance of understanding HTTP basics to correctly obtain and use access tokens.