A Complete Guide to Understanding OAuth 2.0

What is OAuth 2.0

OAuth 2.0 is an open authorization protocol that enables a site to access resources stored on another site without exposing the user’s credentials.

Analogy: a user registers on WeChat, then visits a third‑party website (e.g., www.jiyik.com) that wants to read the user’s friends list and chat history. Instead of providing the website with the WeChat username and password, the user grants limited permission through OAuth 2.0, which can later be revoked.

OAuth 2.0 Architecture

The complete flow contains nine steps:

User accesses a resource through a third‑party application (e.g., Google, WeChat).

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

The user sees the authorization page and decides whether to grant permission.

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

The authorization server issues an authorization code and redirects the user to the client’s pre‑registered redirect URI.

The client receives the redirect URI containing the code.

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

The authorization server validates the request and returns an access token.

With the access token, the client calls the resource server to obtain the protected data.

Key Terminology

Authentication

Identifying a user, typically via username and password.

Federated Authentication

Allows multiple applications to rely on a single identity provider, enabling single‑sign‑on across systems.

Authorization

Granting permission for an action after a user’s identity has been verified.

Delegated Authorization

Providing credentials to another entity so it can act on the user’s behalf.

Roles Defined by OAuth

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

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

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

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

Web Server

A web server delivers pages over HTTP. In OAuth 2.0 the client ID and secret are stored on the web server to keep them confidential.

The diagram shows a confidential client accessing resources on a resource server, with the client ID and secret kept secret on the web server.

User Agent

The user‑side component (e.g., a browser‑based JavaScript app) interacts with the web server.

User accesses resources via an identity provider (Google, WeChat, etc.).

The user agent supplies the client ID and secret to log in to the authorization server.

A JavaScript instance runs in the browser and connects to the web server.

The authorization server permits the client to access the resource server using its credentials.

The resource server returns the protected resources owned by the resource owner.

Native Applications

Desktop or mobile apps that store the client credentials locally on the device.

User accesses resources via an identity provider.

The native app uses its client ID and secret to log in to the authorization server; the credentials are stored on the device.

The authorization server allows the client to fetch resources from the resource server.

The resource server returns the owned data.

Summary

The core of the OAuth 2.0 flow is obtaining an access token, which then enables the client to request protected resources. Understanding the underlying HTTP interactions is essential for implementing the protocol correctly.

Code example

-End-
读到这里说明你
喜欢
本公众号的文章，欢迎
置顶（标星）
本公众号 架构师指南，这样就可以第一时间获取推送了~