OAuth 2.0 and OpenID Connect
OAuth 2.0 and OpenID Connect are closely related, but they solve different problems:
OAuth 2.0
↓
Authorization
"What is this client allowed to access?"
OpenID Connect (OIDC)
↓
Authentication
"Who is this user?"
The easiest rule to remember is:
OAuth 2.0 = Authorization
OpenID Connect = Authentication layer built on OAuth 2.0
1. What Is OAuth 2.0?
What is OAuth 2.0?
OAuth 2.0 is an authorization framework that allows a client application to obtain limited access to a protected resource without requiring the user to give the client their password.
For example:
User
|
v
Angular Application
|
| Request authorization
v
Authorization Server
|
| Access Token
v
Angular Application
|
| Bearer Access Token
v
Order API
OAuth primarily answers:
What is this client allowed to access?
Examples:
orders.read
orders.write
payments.read
profile.read
2. Why Do We Need OAuth 2.0?
Imagine an application wants to access another protected API.
Without OAuth, you might be tempted to give the application:
Username
Password
Then:
Application
|
| Username + Password
v
Protected API
This is problematic because the application now handles the user's credentials.
OAuth changes the model:
User
|
v
Authorization Server
|
| Access Token
v
Application
|
| Access Token
v
Protected API
The client receives a limited credential—an access token—instead of the user's password.
3. Purpose of OAuth 2.0
OAuth provides delegated authorization and application authorization.
It allows systems to answer questions such as:
Can this application read orders?
Can this application update products?
Can Order Service call Payment Service?
Can this application access the user's calendar?
It supports concepts such as:
Access Tokens
Scopes
Client IDs
Authorization Server
Resource Server
Refresh Tokens
Authorization Grants
4. Main OAuth Components
There are four important roles.
+---------------------+
| Resource Owner |
| Usually the User |
+----------+----------+
|
v
+---------------------+
| Client |
| Angular / Mobile |
| Web App / Service |
+----------+----------+
|
v
+---------------------+
| Authorization Server|
| Entra / Keycloak |
| Auth0 etc. |
+----------+----------+
|
Access Token
|
v
+---------------------+
| Resource Server |
| ASP.NET Core API |
+---------------------+
Resource Owner
Usually the person who owns or controls access to the protected resource.
Example:
User
Client
The application requesting access.
Examples:
Angular Application
Mobile Application
ASP.NET Core MVC
Order Microservice
Authorization Server
Authenticates/authorizes according to the selected flow and issues tokens.
Examples include:
- Microsoft Entra ID
- Keycloak
- Auth0
- Duende IdentityServer
Resource Server
The protected API.
For example:
Order API
Payment API
Product API
5. OAuth Access Token
After authorization, the client receives an:
Access Token
It sends it to the API:
GET /api/orders
Authorization: Bearer <access_token>
The API validates the token and checks the relevant permissions.
Conceptually:
Access Token
{
audience: "order-api",
scope: "orders.read",
expires: ...
}
The exact token format and claims depend on the authorization server.
6. OAuth Scope
A scope represents an authorization boundary or permission requested by a client.
For example:
orders.read
orders.write
payments.read
Suppose a token grants:
orders.read
Then:
GET /api/orders
may be allowed.
But:
DELETE /api/orders/1001
could require:
orders.delete
and therefore be denied.
Conceptually:
Access Token
|
+---- orders.read
|
X---- orders.delete
7. OAuth 2.0 Authorization Code Flow
For interactive user applications, an important modern flow is:
Authorization Code + PKCE
For example:
Angular Application
|
| Authorization Request
v
Authorization Server
|
| User authentication /
| consent as applicable
v
Authorization Code
|
v
Angular Application
|
| Code + PKCE verifier
v
Authorization Server
|
v
Access Token
PKCE stands for:
Proof Key for Code Exchange
It helps protect the authorization-code exchange.
8. OAuth Client Credentials Flow
For microservice-to-microservice communication:
Order Service
|
| Client identity
v
Authorization Server
|
| Access Token
v
Order Service
|
| Bearer Token
v
Payment Service
No user is involved.
This is:
OAuth 2.0 Client Credentials
Example:
Order Service
↓
Identity Provider
↓
Service Access Token
↓
Payment Service
The token represents the application/service, not an end user.
9. Important OAuth Flows
| Flow | Typical purpose |
|---|---|
| Authorization Code + PKCE | Interactive user applications |
| Client Credentials | Service-to-service |
| Device Authorization | Devices with constrained input |
| Refresh Token | Obtain a new access token |
| On-Behalf-Of | Common Microsoft scenario for downstream API calls on behalf of a user |
Older flows such as the Implicit Grant and Resource Owner Password Credentials should generally not be chosen for new applications.
10. OAuth 2.0 in ASP.NET Core Microservices
Suppose:
Client
|
| Access Token
v
Order Service
Package commonly used for JWT bearer authentication:
dotnet add package Microsoft.AspNetCore.Authentication.JwtBearer
appsettings.json
{
"Authentication": {
"Authority": "https://identity.example.com",
"Audience": "order-api"
}
}
Program.cs
using Microsoft.AspNetCore.Authentication.JwtBearer;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllers();
builder.Services
.AddAuthentication(
JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.Authority =
builder.Configuration["Authentication:Authority"];
options.Audience =
builder.Configuration["Authentication:Audience"];
options.RequireHttpsMetadata = true;
});
builder.Services.AddAuthorization(options =>
{
options.AddPolicy("ReadOrders", policy =>
{
policy.RequireAuthenticatedUser();
policy.RequireClaim(
"permission",
"orders.read");
});
});
var app = builder.Build();
app.UseHttpsRedirection();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers();
app.Run();
Controller:
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
[HttpGet]
[Authorize(Policy = "ReadOrders")]
public IActionResult GetOrders()
{
return Ok("Orders");
}
}
The exact claim may be scope, scp, roles, or another permission claim depending on your identity provider.
11. Advantages of OAuth 2.0
No need to share user passwords
Applications use tokens rather than passing the user's credentials to protected APIs.
Limited permissions
A token can be limited to particular resources/permissions.
orders.read
rather than unlimited application access.
Token expiration
Access tokens can be short-lived.
Centralized authorization
One authorization server can issue tokens used by many APIs.
Excellent for Microservices
Especially for:
Client → API
and
Microservice → Microservice
Industry standard
OAuth is widely supported by identity platforms and frameworks.
12. Disadvantages of OAuth 2.0
OAuth introduces additional complexity:
- authorization server configuration
- token management
- client registration
- scopes/permissions
- token expiration
- refresh-token handling
- service credentials
- redirect URI configuration
- key/certificate management
Incorrect implementation can also create serious security vulnerabilities.
Therefore, production applications should generally use established OAuth/OIDC libraries rather than implementing the protocols manually.
13. What Is OpenID Connect?
Now the important distinction.
OpenID Connect (OIDC) is an identity/authentication protocol built on top of OAuth 2.0.
OAuth tells us:
What can the client access?
OIDC adds:
Who authenticated?
14. Why Do We Need OpenID Connect?
OAuth was designed primarily for authorization.
Suppose your application needs:
Login with Microsoft
Login with Google
Login with an enterprise identity provider
The application needs reliable information about the authenticated user.
For example:
User ID
Name
Email
Authentication information
OpenID Connect standardizes this identity layer.
15. Purpose of OpenID Connect
OIDC provides authentication capabilities such as:
User login
Identity information
Single Sign-On
Federated authentication
ID Tokens
UserInfo endpoint
Session-related identity features
16. OIDC Introduces the ID Token
This is one of the biggest differences.
OAuth primarily deals with:
Access Token
OIDC introduces:
ID Token
Conceptually:
OAuth
|
+---- Access Token
OIDC
|
+---- ID Token
|
+---- Access Token
The ID Token is normally a JWT containing claims about the authentication event and user.
17. Example ID Token
Conceptually:
{
"sub": "1001",
"name": "Syed",
"email": "syed@example.com",
"iss": "https://identity.example.com",
"aud": "angular-client"
}
It tells the client:
The authenticated user identity
18. Access Token vs ID Token
This is extremely important for interviews.
| Access Token | ID Token |
|---|---|
| OAuth 2.0 concept | OpenID Connect concept |
| Used to access APIs | Used by client to understand authenticated user |
| Sent to Resource Server/API | Intended for the client |
| Contains authorization-related information | Contains authentication/user claims |
| Audience is normally API/resource | Audience is normally client application |
Remember:
ID Token
↓
For Client
Access Token
↓
For API
19. Don't Send ID Token to Your API as the API Credential
A common mistake is:
Client
|
| ID Token
v
Order API
Instead:
Client
|
| Access Token
v
Order API
The ID token tells the client about the authentication.
The access token authorizes access to the resource API.
20. OIDC Login Flow
Suppose you have:
Angular
+
ASP.NET Core Web API
+
Microsoft Entra ID
Flow:
User
|
v
Angular
|
| Login
v
Identity Provider
|
| Authenticate user
v
Authorization Code
|
v
Angular
|
| Code + PKCE
v
Identity Provider
|
+------------------+
| |
v v
ID Token Access Token
| |
v v
Angular Web API
21. Why Are Two Tokens Needed?
Because they serve different consumers.
ID Token
The application needs to know:
Who logged in?
For example:
UserId
Name
Authentication time
Issuer
Access Token
The API needs to know:
Is this token intended for me?
What API permissions does the caller have?
22. openid Scope
How does the authorization server know that the client wants OpenID Connect?
The request includes:
scope=openid
For example:
openid
profile
email
orders.read
Meaning conceptually:
openid
↓
Use OpenID Connect
profile
↓
Request standard profile claims
email
↓
Request email-related claims
orders.read
↓
Request API authorization
openid is the defining scope that turns an OAuth authorization request into an OpenID Connect request.
23. OAuth Only
Suppose Order Service calls Payment Service:
Order Service
|
| Client Credentials
v
Authorization Server
|
| Access Token
v
Payment Service
There is no human user.
Therefore you commonly need:
OAuth 2.0
You generally don't need an ID Token or OIDC user authentication for this pure machine-to-machine interaction.
24. OAuth + OpenID Connect
For user login:
User
|
v
Angular Application
|
v
Identity Provider
You need:
Authentication
+
API Authorization
Therefore:
OIDC
+
OAuth 2.0
are commonly used together.
25. Real Microservices Architecture
Consider:
Angular
|
| Login
v
Microsoft Entra ID
|
+---- ID Token
|
+---- Access Token
|
v
Angular
|
| Access Token
v
API Gateway
|
v
Order Service
|
| Service Access Token
v
Payment Service
There are actually two distinct security scenarios.
User login
Angular
|
v
OIDC
|
v
User Authentication
API authorization
Angular
|
| OAuth Access Token
v
Order API
Service-to-service
Order Service
|
| OAuth Client Credentials
v
Payment Service
This distinction is very important.
26. OAuth vs OIDC vs JWT
These three are often confused.
OAuth 2.0
=
Authorization Framework
OpenID Connect
=
Authentication / Identity Layer
built on OAuth 2.0
JWT
=
Token Format
They are not competitors.
They can work together:
OAuth 2.0
|
Authorization
|
+------ Access Token
|
|
+ OpenID Connect
|
Authentication
|
+------ ID Token
(normally JWT)
And an OAuth access token may also be JWT-formatted, depending on the authorization server.
27. Simple Analogy
Imagine entering a company building.
OpenID Connect
Security checks your identity:
Who are you?
Syed
That's:
Authentication
OAuth
Security determines:
Where are you allowed to go?
Floor 1 ✓
Floor 2 ✓
Server Room ✗
That's:
Authorization
JWT
The badge carrying information such as:
Name
ID
Permissions
Expiration
can be thought of as analogous to the token format.
So:
OIDC
=
Who are you?
OAuth
=
What are you allowed to access?
JWT
=
How token claims may be represented
28. Advantages of OpenID Connect
Standardized authentication
Applications don't need to invent their own identity protocol.
Single Sign-On
A user can authenticate with a centralized identity provider.
Federation
Supports scenarios such as:
Login with Microsoft
Login with Google
Corporate SSO
Standard identity claims
For example:
sub
name
email
Works naturally with OAuth
You can handle both:
Authentication
+
Authorization
within the same overall standards ecosystem.
29. Disadvantages of OpenID Connect
More concepts
Developers need to understand:
ID Token
Access Token
Authorization Code
Scopes
Claims
Redirect URIs
PKCE
Discovery
Configuration complexity
Incorrect issuer, audience, redirect URI, or client configuration can cause failures or security issues.
Identity provider dependency
Authentication relies on the identity infrastructure.
30. Key Points
Remember these for interviews.
OAuth 2.0
Purpose:
Authorization
Main Token:
Access Token
Used for:
API access
Service-to-service access
Example:
Order Service → Payment Service
OpenID Connect
Purpose:
Authentication
Built on:
OAuth 2.0
Important Token:
ID Token
Used for:
User login
SSO
Identity
JWT
Purpose:
Token format
Contains:
Claims
Can be used as:
ID Token
Access Token
31. Interview Questions and Answers
Q1. What is OAuth 2.0?
Answer:
OAuth 2.0 is an authorization framework that allows a client to obtain limited access to protected resources using access tokens rather than sharing the user's credentials with the resource API.
Q2. What is OpenID Connect?
Answer:
OpenID Connect is an authentication and identity layer built on OAuth 2.0. It allows applications to authenticate users and receive identity information through an ID Token and related OIDC mechanisms.
Q3. OAuth vs OpenID Connect?
Answer:
The simplest distinction is:
OAuth 2.0
→ Authorization
OpenID Connect
→ Authentication
OIDC extends OAuth 2.0 with standardized identity capabilities.
Q4. What is an Access Token?
Answer:
An access token is a credential presented to a protected resource/API to obtain authorized access.
Client
|
| Access Token
v
API
Q5. What is an ID Token?
Answer:
An ID Token is an OpenID Connect token containing claims about the authenticated user and authentication event. It is intended for the client application.
Identity Provider
|
| ID Token
v
Client
Q6. Access Token vs ID Token?
Answer:
Access Token
→ For API
ID Token
→ For Client
An access token authorizes resource access, while an ID token communicates authenticated identity information to the client.
Q7. Is OAuth an authentication protocol?
Answer:
OAuth 2.0 is primarily an authorization framework. OpenID Connect adds the standardized authentication/identity layer.
Using an OAuth access token merely as proof that a user logged in is a common conceptual mistake.
Q8. Is JWT the same as OAuth?
Answer:
No.
OAuth
=
Authorization framework
JWT
=
Token format
An OAuth access token may be JWT-formatted, but it does not have to be.
Q9. Is JWT the same as OpenID Connect?
Answer:
No.
OIDC is an authentication protocol, while JWT is a token format. OIDC ID Tokens are JWTs.
Q10. Which OAuth flow is normally used between Microservices?
Answer:
For a service acting on its own behalf:
Client Credentials
Order Service
|
v
Authorization Server
|
| Access Token
v
Payment Service
Q11. Which flow should Angular use?
For a browser-based SPA requiring user authentication and API access, a common modern approach is:
Authorization Code Flow with PKCE
Angular
|
v
Authorization Server
|
| Authorization Code
v
Angular
|
| Code + PKCE
v
Authorization Server
|
+---- ID Token
|
+---- Access Token
Q12. What is the openid scope?
Answer:
openid indicates that the client is making an OpenID Connect authentication request.
For example:
scope =
openid profile email orders.read
Without the openid scope, it isn't an OIDC authentication request.
OAuth vs OIDC — Interview Table
| Feature | OAuth 2.0 | OpenID Connect |
|---|---|---|
| Main purpose | Authorization | Authentication |
| Main question | What can you access? | Who are you? |
| Built on | — | OAuth 2.0 |
| Access Token | Yes | Commonly alongside OIDC |
| ID Token | No | Yes |
| API authorization | Yes | Uses OAuth |
| User authentication | Not its primary purpose | Yes |
| SSO | Not by itself | Yes |
| Service-to-service | Yes | Usually unnecessary for pure S2S |
| Important scope | API scopes | openid |
| Common flow | Client Credentials | Authorization Code + PKCE |
Final Architecture to Remember
Identity Provider
/ Authorization Server
^
|
OAuth 2.0 + OpenID Connect
|
|
User ---> Angular -------------+
|
| ID Token
| └── tells Angular who authenticated
|
| Access Token
v
API Gateway
|
v
Order Service
|
| OAuth 2.0
| Client Credentials
|
| Service Access Token
v
Payment Service
Short Interview Answer
OAuth 2.0 is an authorization framework used to give clients limited access to protected APIs through access tokens. OpenID Connect is an authentication layer built on OAuth 2.0 that adds user identity and login capabilities, primarily through the ID Token. In microservices, OAuth 2.0 can secure both client-to-API and service-to-service access, while OIDC is commonly used when a user needs to authenticate or use SSO. The simplest way to remember the difference is: OAuth answers "what can you access?", OIDC answers "who are you?", and JWT is a token format that can be used by these protocols.