Understanding OAuth2.0: Principles, Architecture, and Implementation

When I first encountered OAuth2.0 I often confused it with SSO (single sign‑on). After implementing an SSO system at work I realized the differences and wrote a separate article on SSO; now I revisit OAuth2.0 to clarify its principles and implementation.

What is OAuth2.0

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

To make the abstract definition concrete, imagine a scenario where a user registers on WeChat, adds friends, and has chat history. The user then wants to use a website (e.g., www.jiyik.com) that can read that chat data for analysis. Instead of giving the website the user’s WeChat username and password, the user can grant limited permission via OAuth2.0, and later revoke that permission.

The complete OAuth2.0 process involves three entities:

Resource Owner (e.g., the WeChat user)

Client Application (the third‑party website)

Authorization Server (e.g., WeChat’s OAuth service)

When a third‑party site wants to allow login with a WeChat account, the same authorization mechanism provides a form of single sign‑on.

OAuth2.0 Architecture

The overall flow is as follows:

1. The user accesses a third‑party application using Google, WeChat, etc.

2. The third‑party site redirects the user to the resource server’s authorization page, passing its client ID and client secret.

3. The user sees the authorization screen and grants permission.

4. The user authenticates; the client ID and secret uniquely identify the client on the authorization server.

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

6. The client receives the code in the redirect URI.

7. The client exchanges the code, client ID, and client secret for an access token.

8. The authorization server returns the access token to the client.

9. With the access token, the client can call the resource server to access the user’s protected resources.

This flow involves several HTTP concepts; refer to an HTTP tutorial for details.

Terminology

Authentication

Authentication is the process of verifying a user’s identity, typically using a username and password.

Federated Authentication

Federated authentication allows multiple systems to share a single sign‑on experience.

Authorization

Authorization is the process of granting a user permission to perform an action after their identity has been verified.

Delegated Authorization

Delegated authorization lets a user grant another entity the right to act on their behalf.

Roles

OAuth defines four roles:

Resource Owner – the entity that can grant access to its data (the end user).

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

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

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

Web Server

A web server is a computer system that uses HTTP to deliver web pages. In OAuth, the client ID and secret are stored on the web server to keep them confidential.

In this diagram the resource owner authorizes a confidential client, whose ID and secret are stored securely on the server.

User Agent

The user‑agent application runs on the user’s device (e.g., JavaScript in a browser) and can be hosted on a web server.

Native Application

A native app (desktop or mobile) can also act as an OAuth client, storing its client ID and secret on the device.

The native app follows a similar flow: obtain authorization code, exchange it for an access token, and then access the resource server.

Summary

The article has introduced the complete OAuth2.0 flow, explained key terminology, and highlighted the importance of understanding HTTP basics to obtain and use access tokens effectively.

After the technical tutorial, the author adds promotional material for a ChatGPT‑related community, private‑account services, and interview question resources.