Understanding OAuth 2.0: Scenarios, Flow, and Implementation Details

1. Application Scenarios

OAuth (Open Authorization) is an open standard that lets users grant third‑party applications access to their private resources (e.g., messages, photos, contacts) on a website without sharing their username and password.

Typical use case: a user logs into a new website (Site A) using a third‑party account such as WeChat. Site A redirects the user to WeChat for authentication, obtains the user's basic WeChat profile, and logs the user in without requiring a separate registration.

Problems arise if Site A were to receive the user's WeChat password directly, which would expose all of the user's WeChat data and make the password a single point of failure.

1、This is insecure – I only want to give Site A my WeChat basic info, not all info via password.
2、Only changing the password revokes Site A's access, but it also invalidates all other authorized third‑party apps.
3、If any third‑party app is compromised, the user's password and all password‑protected data leak.

OAuth was created to solve these problems.

The model involves three main entities:

User

The user can log in to a new site using a third‑party account, avoiding a complex registration process.

Third‑Party Platform (e.g., WeChat)

The platform provides a unique credential to the service provider after a credential review.

Service Provider (Site A)

The service provider connects to the third‑party platform, obtains the user's basic information after the user authorizes, and completes the login.

2. OAuth Idea

OAuth introduces an authorization layer between the service provider and the third‑party platform. The service provider cannot log directly into the platform; it must interact with the authorization layer using a token, which is distinct from the user's password.

The token’s scope and expiration are defined by the user at login time, and the platform grants the service provider access to the user's stored data based on that token.

1. Pre‑Integration Preparation (Credential Review)

If a service provider wants to use a third‑party platform, it first submits its credentials for review. After approval, the platform issues a unique identifier (ID) that the provider uses in subsequent authorization requests.

Typical parameters returned:

appid  – the application’s unique ID
appsecret – the corresponding secret key

Note: Different platforms may use different parameter names; the purpose is always to verify the application’s identity.

2. User Initiates Third‑Party Login

The server (Site A) receives a login request, builds the platform‑specific URL using the previously obtained appid , and redirects the user to that URL.

www.xxx.com/oauth2.0/authorize?appid=123456&redirect=www.sss.com/login

Key parameters:

appid – the application’s unique ID on the third‑party platform
redirect – URL to which the platform redirects after the user grants permission (usually the site’s login page)

The user is redirected to the platform’s authorization page.

3. User Grants Authorization

After the user approves, the platform redirects back to the redirect URL with an authorization code .

www.sss.com/login?code=xxxxx

4. Exchange Code for Access Token

The server receives the code and makes a request to the platform to exchange it for an access_token .

code – the authorization code returned by the platform
appid – application ID
appsecret – application secret

www.xxx.com/oauth2/access_token?appid=xxxx&secret=xxxx&code=xxxx

If successful, the platform returns an access_token , which represents the user’s authorization for the application, along with basic user information such as a unique user ID.

5. Retrieve User Information

Using the access_token , the application can request the user’s profile data from the platform.

6. Additional Notes

1. After successful WeChat authentication, the access_token can be stored in a cookie so the user does not need to re‑authorize on each visit.
2. access_token has an expiration time (e.g., 2 hours for WeChat QR‑code login).
3. When the access_token expires, the refresh_token (issued together with the access_token) can be used to obtain a new access_token without user interaction; its validity is longer (e.g., 30 days).
4. Only when the refresh_token also expires does the user need to re‑authorize.

For detailed specifications, refer to the official WeChat login documentation: WeChat Login Development Guide .

References

1. "Easy Understanding of OAuth2.0 (with many diagrams)" – thank you for the source.

2. "OAuth2.0 Knowledge (practical)".