Hello! In our previous lesson, we dove into fine-grained, internal authorization with @PreAuthorize, answering the question, "What is this user allowed to do inside our application?"
Today, we're zooming out to tackle a fundamental aspect of modern application security: how to interact with external identity systems. When you see a "Sign in with Google" button, you're looking at the result of the protocols we'll discuss. This lesson addresses how your application can securely access resources on behalf of a user without ever handling their password.
Your learning outcome is to explain the core concepts of OAuth2 (roles, grant types) and OpenID Connect (OIDC). For a senior engineering interview, a solid grasp of these concepts is non-negotiable, as they form the bedrock of security in microservices and distributed systems.
1. The Problem: Delegated Authorization
Before OAuth2, a common but insecure pattern existed. Imagine an application, "CoolPhotoPrinter," wants to print photos from your Facebook account. Without a standard protocol, it might ask for your Facebook username and password.
This is a terrible idea for several reasons:
- You are giving your full Facebook credentials to a third-party application.
- "CoolPhotoPrinter" now has access to everything in your account (messages, posts, etc.), not just your photos. This violates the principle of least privilege.
- If "CoolPhotoPrinter" has a security breach, your Facebook credentials are stolen.
OAuth 2.0 was created to solve this exact problem, which is known as delegated authorization. It allows a user to grant a third-party application limited access to their resources on another service, without sharing their credentials.
To understand the core problem that led to OAuth 2.0, watch this introductory segment.
OAuth 2.0 and OpenID Connect (in plain English)
This video from the OktaDev channel provides an excellent, real-world example of the 'delegated authorization' problem that OAuth 2.0 was designed to solve. The 'Yelp example' is a classic illustration of the anti-pattern.
Watch from 08:59 to 13:09. Focus on understanding why asking for a user's password is a flawed approach and how delegated authorization provides a more secure alternative.
This brings us to a crucial distinction you must be able to articulate in an interview:
- Authentication (AuthN): The process of verifying who you are. (e.g., logging in with a username and password).
- Authorization (AuthZ): The process of verifying what you are allowed to do. (e.g., checking if you have permission to read a specific file).
OAuth 2.0 is an authorization framework, not an authentication protocol. It is designed to grant permissions, not to verify a user's identity. We'll see how OpenID Connect (OIDC) later fills this gap.
2. The Core of OAuth 2.0: Roles and the Authorization Code Flow
To understand how OAuth 2.0 works, we first need to define the actors involved.
Advanced OAuth 2.0 Interview Questions
This article from Second Talent provides a concise, interview-ready definition of the four main roles in the OAuth 2.0 framework.
Read the first question, 'What are the four roles defined in the OAuth 2.0 framework?'. Memorize these roles and what they represent.
To summarize, the four roles are:
- Resource Owner: The user who owns the data (e.g., you).
- Client: The application that wants to access the data (e.g., "CoolPhotoPrinter").
- Authorization Server: The server that authenticates the Resource Owner and issues access tokens (e.g.,
accounts.google.com). - Resource Server: The API that hosts the protected data (e.g., the Google Photos API).
Now, let's see how these roles interact in the most common and secure OAuth 2.0 flow: the Authorization Code Flow. This flow is designed to ensure that sensitive tokens are never exposed in the user's browser (the "front-channel").
OAuth 2.0 and OpenID Connect (in plain English)
This segment of the OktaDev video provides a step-by-step visual walkthrough of the Authorization Code Flow. It introduces key terminology like 'access token' and 'redirect URI' and shows how they fit together.
Watch from 15:44 to 22:15. Follow the diagram closely to understand how the Client gets an 'authorization code' from the user's browser and then exchanges it for an 'access token' on the back-channel.
A key aspect of this flow is the concept of scopes. The Client doesn't just ask for access; it asks for specific, granular permissions.
OAuth 2.0 and OpenID Connect (in plain English)
Continuing with the same video, this next part explains how 'scopes' are used to limit the permissions an application requests, adhering to the principle of least privilege.
Watch from 22:15 to 26:35. Note how the requested scopes are presented to the user on the consent screen and how the final access token is bound to those specific scopes.
Senior-Level Deep Dive: Front-Channel vs. Back-Channel
A common senior interview question is: "Why does the Authorization Code flow have a two-step process of getting a code and then exchanging it for a token? Why not just return the token directly?"
The answer lies in understanding the security differences between the front-channel (the user's browser, which is less trusted) and the back-channel (direct server-to-server communication, which is highly trusted).
OAuth 2.0 and OpenID Connect (in plain English)
This is one of the most important conceptual segments for a senior-level interview. It explains the security rationale behind the design of the Authorization Code Flow.
Watch from 26:35 to 36:06. Focus on why the sensitive access token is only ever transmitted on the secure back-channel, while the less-sensitive authorization code is passed through the browser's front-channel.
3. Choosing the Right Tool: OAuth 2.0 Grant Types
The "Authorization Code Flow" is a type of grant. A grant type is simply a specific flow for obtaining an access token. OAuth 2.0 defines several grant types for different use cases. Choosing the right one is critical for security.
Advanced OAuth 2.0 Interview Questions
This guide provides excellent, up-to-date descriptions of the most important grant types, including modern best practices like PKCE.
Read the 'Grant Types & Flows' section. Pay close attention to: Authorization Code Flow with PKCE: Why it's the current best practice for ALL clients. Client Credentials Grant Flow: Its use case for machine-to-machine (M2M) communication. Why the Implicit Grant and ROPC grants are no longer recommended.
Here is a summary for your interview preparation:
| Grant Type | Use Case | Security Level | Key Characteristic |
|---|---|---|---|
| Authorization Code (+ PKCE) | Web apps with a backend, Single-Page Apps (SPAs), Mobile apps. This is the default. | High | User interaction via browser. Code is exchanged for a token on the back-channel. |
| Client Credentials | Machine-to-machine (M2M) communication, e.g., a backend service calling another. | High | No user is involved. The client authenticates itself with a client ID and secret. |
| Resource Owner Password (ROPC) | Legacy applications where redirects are impossible. Highly discouraged. | Low | The client collects the user's actual username and password. Breaks the OAuth model. |
| Implicit Grant | Old SPAs. Deprecated and no longer recommended. | Low | The access token is returned directly in the browser URL, exposing it. |
Test your understanding!
An interviewer asks: "You are designing a system with three components: a React single-page application (the frontend), a Spring Boot 'Orders Service' (a microservice), and a Spring Boot 'Inventory Service' (another microservice). The Orders Service needs to call the Inventory Service to check stock levels. Which OAuth 2.0 grant type should be used for the communication between the Orders Service and the Inventory Service, and why?"
Show answer
The correct answer is the Client Credentials Grant.
Why: The communication is between two backend services (machine-to-machine) and does not involve a user's direct interaction or consent for that specific call. The Orders Service is acting on its own behalf, not on behalf of a user in that context. It would authenticate itself to the Authorization Server using its own client_id and client_secret to get a token that allows it to talk to the Inventory Service.
4. The Missing Piece: OpenID Connect (OIDC) for Authentication
We've established that OAuth 2.0 is for authorization. It answers, "What can this app do on my behalf?" but it never answers, "Who am I?"
This is where OpenID Connect (OIDC) comes in. OIDC is a thin identity layer built on top of OAuth 2.0. It standardizes the way clients can get identity information about the authenticated user.
OAuth 2.0 and OpenID Connect (in plain English)
The final segments of the OktaDev video clearly explain why OAuth 2.0 alone is insufficient for authentication and how OIDC extends it to solve this problem.
Watch from 45:53 to 56:31. This is a critical section. Focus on: The problem with using 'hacks' on top of OAuth 2.0 for login. How OIDC introduces the openid scope and the id_token. The structure of the id_token (a JSON Web Token - JWT) and its purpose.
The most important concept OIDC introduces is the id_token. You must be able to differentiate it from an access_token.
| Token | Purpose | Audience | Content |
|---|---|---|---|
access_token |
Authorization. To access an API. | The Resource Server (the API). | Can be an opaque string or a JWT. The client should not try to read it. Its format is for the API to understand. |
id_token |
Authentication. To prove who the user is. | The Client (your application). | Always a JWT. Contains claims about the user (like sub for subject/user ID, email, etc.) and the authentication event. |
In an OIDC flow, the client requests both an access_token and an id_token. It uses the id_token to understand who the user is (and maybe create a local session), and it uses the access_token to make calls to protected APIs (Resource Servers) on the user's behalf.
Conclusion
You have now explored the foundational protocols for modern delegated authorization and federated identity. Understanding the clear separation of concerns between OAuth 2.0 and OIDC is a hallmark of a senior developer.
Key Takeaways for Your Interview Prep:
- OAuth 2.0 is for Authorization: It delegates permission for a client to act on behalf of a user. It is not for authentication.
- OIDC is for Authentication: It's a layer on top of OAuth 2.0 that provides a standard way to get information about the authenticated user via an
id_token. - Know the Roles: Resource Owner, Client, Authorization Server, Resource Server.
- Default to Authorization Code + PKCE: This is the most secure and recommended grant type for any application with user interaction.
- Use Client Credentials for M2M: This is the correct pattern for service-to-service communication in a microservices architecture.
access_tokenvs.id_token: Theaccess_tokenis for the API (Resource Server). Theid_tokenis for your app (Client). Never send anid_tokento an API as a bearer token.
Preview of the Next Lesson:
Now that we've covered how to secure access to our APIs using JWTs, method security, and OAuth2/OIDC, the next logical step is to focus on the design of the APIs themselves. In the next lesson, we will cover how to design resource-oriented URIs with appropriate HTTP methods and status codes, a core principle of building clean, understandable, and maintainable REST APIs.