Information Security 13 min read

Understanding OAuth2.0: Principles, Architecture, and Implementation

This article explains the fundamentals of OAuth2.0, distinguishes it from SSO, describes the roles of resource owner, client, authorization server and resource server, outlines the step‑by‑step authorization flow, and clarifies related terminology such as authentication, federated identity, and delegated authorization.

Top Architect
Top Architect
Top Architect
Understanding OAuth2.0: Principles, Architecture, and Implementation

Hello, I am a senior architect.

What is OAuth2.0

OAuth is an open authorization protocol and the most widely used mechanism today. It enables a site to share resources stored on another site without requiring the latter's credentials.

To make the concept easier, imagine a scenario where a user registers a WeChat account, adds friends, and has chat history, and then wants to use a third‑party website (e.g., www.jiyik.com) that wants to read that chat data for analysis. Instead of giving the website the user’s WeChat username and password, the user can grant limited permissions via OAuth2.0, and later revoke them if desired.

A complete OAuth2.0 flow involves three entities:

Resource Provider (e.g., WeChat, Google, Facebook)

Third‑party website / application

User

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

OAuth2.0 Architecture

The overall process is as follows:

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

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

The user sees the provider’s login/consent screen and authorizes the request.

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 predefined redirect URI.

The client receives the code, then sends the code together with its client ID and secret to the authorization server.

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

With the access token, the client can now request protected resources from the resource server on behalf of the user.

This flow relies on HTTP concepts; refer to our HTTP tutorial for details.

Terminology

Authentication

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

Federated Authentication

Many third‑party applications have their own credentials, but they may rely on another service to authenticate users. A federated identity system provides single access across multiple systems.

Authorization

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

Delegated Authorization

Delegated authorization allows a user to give another entity the right to act on their behalf using the user’s credentials.

Roles

OAuth defines the following roles:

Resource Owner – the entity (often an end‑user) that can grant access to data stored on the resource server.

Client Application – the application that makes protected‑resource requests on behalf of the resource owner.

Resource Server – the API server that hosts the user’s data.

Authorization Server – the server that obtains permission from the resource owner and issues access tokens to the client.

Web Server

A web server delivers web pages to users via HTTP. Client IDs and secrets are stored on the web server to keep them confidential.

In the diagram, the resource owner permits a confidential client to access data hosted on the resource server; the client ID and secret are stored securely on the server.

User Agent

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

The client‑side user‑agent architecture is shown below.

Native Application

A native application can be a desktop or mobile client that uses the resource owner’s credentials. The credentials are embedded in the application code, so native apps should not be used in untrusted user‑agent environments.

Summary

We have presented the complete OAuth2.0 flow, explained the associated terminology, and highlighted the importance of understanding HTTP basics, since the core of the process is obtaining an access token.

Feel free to discuss, ask questions, or contact the author for further clarification.

Additional resources and promotional links are provided throughout the article.

securityAuthenticationWeb DevelopmentAuthorizationOAuth2.0
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.