← Back to Article List         
OAuth 2.0 & OpenID Connect

OAuth 2.0 & OpenID Connect

Published on 29 Sep 2026     14 min read Microservices
Authentication & Security

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.