Token-Based Authentication Architecture Using OAuth2 and JWT
The article explains the design and implementation of a token‑based authentication system for micro‑services, covering terminology, business background, OAuth2 password‑grant flow, JWT usage, security advantages, functional modules, technical choices, detailed authentication workflow, and API design.
Term Definitions
Third‑party application: also called "client". HTTP service: the service provider. Resource Owner: the user who logs in. User Agent: the browser. Authorization server: server that handles authentication. Resource server: server that stores user‑generated resources; may be the same as the authorization server.
R&D Background
As enterprise applications proliferate, isolated user data creates information silos; a unified, standardized account management system becomes essential for platform‑level capabilities such as single sign‑on and third‑party login, providing a foundation for open platforms and ecosystems.
In monolithic systems, authentication is often performed via a session stored in memory; with the rise of RESTful APIs and micro‑services, token‑based authentication is increasingly common because a token carries user information and can be verified without server‑side state.
Advantages of token‑based authentication:
Stateless on the server: the token itself contains all necessary user data.
Better performance: verification does not require database or remote service calls.
Supports mobile devices and cross‑application calls; unlike cookies, tokens are not limited by domain restrictions.
R&D Goal
Provide a standard, secure authentication process that enables flexible integration and unified security across heterogeneous systems and services.
Typical token authentication flow:
User submits login credentials (or calls a token endpoint) to the authentication service.
The service validates the credentials and returns a token containing user info, permission scope, and expiration.
The client includes the token in HTTP request headers when calling APIs.
The called micro‑service validates the token and permissions.
The service returns the requested resources and data.
Security Authentication Functional Points
Credential acquisition: third‑party client obtains an Access Token from the authorization server using client credentials and user credentials.
Login authorization: client presents the Access Token to the resource server, which validates the token, client credentials, and user legitimacy before granting access.
Access verification: resource server checks token validity and permission before returning the resource.
Credential renewal: when an Access Token expires, a refresh token is used to obtain a new token.
Technical Selection Analysis
System authorization adopts the OAuth2 password‑grant flow. Tokens follow the JWT standard.
1. OAuth Open Authorization
OAuth (Open Authorization) defines a secure, open, and simple standard for granting user resources without exposing usernames or passwords to third‑party applications.
Four main grant types:
Authorization Code: used between client and server applications.
Implicit: used by mobile or web apps where the token is returned directly to the browser.
Password (Resource Owner Password Credentials): trusted clients receive the user's username and password to obtain a token.
Client Credentials: the client authenticates on its own behalf, not on behalf of a user.
2. JSON Web Token (JWT)
JWT is an open, JSON‑based standard (RFC 7519) for transmitting claims securely and compactly, ideal for distributed single sign‑on scenarios. Claims convey authenticated user identity and can include additional business‑specific information; tokens may be signed and optionally encrypted.
Authentication Process Logic
1. System Authorization
The third‑party client uses its client ID/secret and the resource owner's credentials to obtain an Access Token from the authorization server.
System authorization issues an Access Token to the client application.
2. System Authentication
The client sends the Access Token in the request header; the resource server validates the token, client credentials, and user legitimacy, then loads the user's permissions to complete login.
After validation, the resource server returns the requested resource data.
3. Credential Renewal
When the Access Token expires, a refresh token is used to obtain a new token with extended validity.
API Design
1. Authorization Credential
Endpoint to obtain an authorization credential; validates client identity and resource owner identity, then issues a token.
Client ID/secret must be generated after the third‑party application passes registration review.
2. Credential Renewal
Endpoint to refresh the authorization credential; validates client identity and the refresh token before issuing a new token.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.