OAuth 2.0: Principles, Architecture, and Implementation Overview

What is OAuth 2.0

OAuth is an open authorization protocol and the most widely used mechanism for granting limited access to resources without sharing user credentials.

To illustrate the idea, imagine a user who has a WeChat account with friends and chat history and wants to let a third‑party website (e.g., www.jiyik.com) analyze that data without giving the site their password.

The user can authorize the site via OAuth 2.0, granting specific permissions that can later be revoked, avoiding the security risks of sharing credentials.

A complete OAuth 2.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)

When a third‑party site wants to allow login with a WeChat account, the same authorization mechanism provides a form of single sign‑on, which is why OAuth is often confused with SSO.

OAuth 2.0 Architecture

The overall process is as follows:

The user accesses a third‑party application using a provider such as Google or WeChat.

The client redirects the user to the provider’s authorization page, sending its client ID and client secret.

The user sees the provider’s consent screen and decides whether to grant access.

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

After consent, the authorization server redirects the user back to a pre‑registered redirect URI, attaching an authorization code.

The client receives the code at the redirect URI.

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

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

With the access token, the client can call the resource server to obtain the protected resources.

This flow relies on underlying HTTP concepts (see our HTTP tutorial for details).

Key Terminology

Authentication

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

Federated Authentication

Federated authentication allows multiple applications to rely on a single identity provider, enabling single access across systems.

Authorization

Authorization is the act of granting permission to perform certain actions after a user’s identity has been verified.

Delegated Authorization

Delegated authorization lets a user grant another application the right to act on their behalf without sharing credentials.

Roles Defined by OAuth

OAuth defines four primary roles:

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 resources.

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

Web Server

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

The resource server hosts data from providers such as Google or WeChat, while the authorization server validates client credentials and issues tokens.

User Agent

The user‑agent is typically a browser‑based JavaScript application that interacts with the web server during the OAuth flow.

Native Applications

Native apps (desktop or mobile) can also act as OAuth clients, storing client credentials locally. However, embedding secrets in a native app is discouraged because they can be extracted.

Summary

The article presented the complete OAuth 2.0 workflow, explained the involved terminology, and highlighted the need to understand HTTP basics to grasp token acquisition and usage.

Note: The original article ends with promotional material encouraging readers to follow the “Linux技术迷” public account for additional resources.