Understanding OAuth 2.0: Roles and Grant Types

Hello! Welcome to the first lesson of Module 6, where we pivot from performance and concurrency to another critical pillar of production-ready microservices: security.

In the last module, we concluded by designing a multi-level caching strategy, an advanced technique to optimize the performance of read-heavy services. Now, we will secure those services. In a distributed system, ensuring that only legitimate users and services can access your APIs is paramount.

This lesson addresses the learning outcome: Explain the OAuth 2.0 framework, including roles (Resource Owner, Client, etc.) and common grant types. OAuth 2.0 is the industry standard for authorization in modern applications. For your interviews at FAANG and major fintech companies, you will be expected to articulate not just what it is, but why specific patterns are chosen for different scenarios. We'll focus on building that deep understanding of the "why" and "when."

1. What is OAuth 2.0 and Why Do We Need It?

Before OAuth 2.0, it was common for applications to ask for your username and password to access data from another service (e.g., a third-party app asking for your Google password to import contacts). This pattern, known as password sharing, is extremely insecure.

To understand the problems OAuth 2.0 was designed to solve, please read the following section from an article by LoginRadius.

As you just read, OAuth 2.0 was created to replace this insecure model. Its core concept is delegated authorization.

OAuth 2.0 allows a user to grant a third-party application limited access to their resources on another service, without exposing their credentials.

A crucial distinction to make in any interview is between authentication and authorization:

• Authentication is about verifying identity ("Who are you?").
• Authorization is about granting permissions ("What are you allowed to do?").

OAuth 2.0 is a framework for authorization. To see this in action, let's watch a short, clear explanation.

2. The Core Roles in OAuth 2.0

The OAuth 2.0 framework defines four fundamental roles. Understanding who is who is essential to making sense of the data flows.

Let's dive into what each role does. The following article gives precise definitions, including a critical distinction between client types that will be important later.

Let's map these roles to a typical microservices architecture you might discuss in an interview:

• Resource Owner: The end-user trying to access their data through an application.
• Resource Server: Your Spring Boot microservice that exposes a protected API (e.g., /api/orders). It holds the data.
• Client: The application the user interacts with. This could be a React Single-Page Application (SPA) or a mobile app.
• Authorization Server: A dedicated service that handles user login, consent, and issues tokens. In production, this is often a specialized product like Keycloak, Okta, or Spring Authorization Server.

3. The "Currency" of OAuth 2.0: Tokens and Scopes

OAuth 2.0 flows revolve around the exchange of tokens. These are special credentials that represent the authorization granted to the client.

Here's a summary of these critical concepts:

• Access Token: A short-lived credential used to access a protected resource (your API). It's included in the Authorization header of an HTTP request. It can be a JWT (JSON Web Token), which is self-contained and can be validated locally by the resource server, or an opaque token, which is just a random string that the resource server must validate by calling the authorization server.
• Refresh Token: A long-lived credential used to obtain a new access token once the old one expires. It is sent only to the authorization server, never to the resource server. This pattern allows for long-lived user sessions without storing long-lived, high-privilege access tokens on the client.
• Scopes: These define the specific permissions the client is requesting (e.g., read:orders, write:profile). They allow for the principle of least privilege, ensuring a client only gets the access it truly needs.

4. Grant Types: The "How" of Getting a Token

A grant type is a specific flow for obtaining an access token. OAuth 2.0 defines several grant types, each tailored to a different kind of client or use case. Choosing the right one is a common interview question.

The table below summarizes the key grant types and their primary use cases.

Application Type	Recommended Grant Type	Key Characteristics
Server-side Web App (e.g., a Spring MVC app)	authorization_code	Confidential client. Can securely store a client_secret. Token exchange happens on the backend.
SPA (Browser) or Mobile App	authorization_code with PKCE	Public client. Cannot store a secret. PKCE adds a security layer to prevent token theft.
Machine-to-Machine (M2M) (e.g., microservice A calls B)	client_credentials	No user involved. The client authenticates itself using its client_id and client_secret.
Smart Devices / IoT (e.g., Smart TV)	device_authorization	For devices with limited input. The user authorizes on a separate device (e.g., their phone).
Legacy / Highly Trusted Apps	password (ROPC) / implicit	DEPRECATED. Avoid these. They are insecure and violate core OAuth principles.

For a more detailed explanation of these flows, including why some are now discouraged, the LoginRadius article is an excellent resource.

Let's visualize the most common user-facing flow: the Authorization Code Flow. This diagram illustrates the sequence of interactions between the roles.

The key steps are:

1. Authorization Request: The Client redirects the user to the Authorization Server.
2. User Consent: The user logs in and grants permission.
3. Authorization Code: The Authorization Server redirects the user back to the Client with a temporary code.
4. Token Exchange: The Client sends the code (and its client_secret if it's a confidential client) to the Authorization Server's token endpoint. For public clients, this is where PKCE (Proof Key for Code Exchange) happens, adding an extra verification step.
5. Access Token: The Authorization Server validates the code and returns an access_token and a refresh_token.
6. Resource Access: The Client uses the access_token to make secure calls to the Resource Server (your API).

Test your understanding!

You are designing the security for an e-commerce platform. You have the following components:

1. A React single-page application (SPA) that customers use to browse products and place orders.
2. An "Order Service" microservice that needs to call an internal "Payment Service" microservice to process payments.
3. A nightly batch job (a standalone Java application) that calls various internal services to generate sales reports.

For each of these scenarios, which OAuth 2.0 grant type would you recommend, and why?

Show answer

1. React SPA: Authorization Code with PKCE.

   • Why: The SPA is a public client—it runs in the user's browser and cannot securely store a client_secret. The Authorization Code flow ensures tokens are not exposed in the URL. PKCE is essential to prevent a malicious actor who intercepts the authorization code from exchanging it for a token.

2. Order Service calling Payment Service: Client Credentials.

   • Why: This is a machine-to-machine (M2M) interaction. There is no user directly involved in the call. The Order Service acts on its own behalf. It's a confidential client (a backend service) and can securely use its client_id and client_secret to obtain a token representing its own identity.

3. Nightly Batch Job: Client Credentials.

   • Why: Similar to the M2M case, this is a non-interactive process. The batch job is a client that needs to access APIs on its own authority. The Client Credentials grant is designed for exactly this kind of unattended, backend process.

Conclusion

In this lesson, we've laid the theoretical foundation for securing microservices. You can now explain what OAuth 2.0 is, the roles involved, and, most importantly, how to choose the right authorization flow for different architectural scenarios—a key skill for system design and senior-level interviews.

Key Takeaways:

• OAuth 2.0 is a framework for delegated authorization, not authentication. It allows clients to access resources on behalf of a user without handling their password.
• The four core roles are Resource Owner, Client (Public vs. Confidential), Authorization Server, and Resource Server.
• Grant types are flows for obtaining tokens. The choice depends on the client type and use case.
• For modern applications, the key grant types to know are:
  • Authorization Code with PKCE for public clients (SPAs, mobile apps).
  • Client Credentials for machine-to-machine communication.
• Older grant types like Implicit and Resource Owner Password Credentials (ROPC) are deprecated due to security vulnerabilities.

Next Up

Now that you understand the theory, it's time to put it into practice. In our next lesson, we will begin implementing this knowledge. Our goal will be to set up a Spring Authorization Server and register an OAuth2 client with support for the authorization_code grant type. This will be our first step toward building a secure, production-ready microservices ecosystem.