OAuth 2.0 & OpenID Connect

Modern applications need secure ways to authenticate users and allow controlled access to protected resources. With the growth of cloud applications, microservices, and mobile platforms, traditional authentication approaches are often not enough.

OAuth 2.0 and OpenID Connect have become widely adopted identity standards that help applications securely authenticate users and authorize access to APIs and services.

Why Modern Applications Need Identity Protocols

Applications today rarely operate in isolation. Users access systems from web browsers, mobile applications, APIs, and third-party platforms.

A secure identity system must provide:

• Secure user authentication
• Controlled API access
• Token-based security
• Single Sign-On capabilities
• Integration with external identity providers
• Protection of sensitive user information

Authentication vs Authorization

Authentication and authorization solve different security problems.

Authentication	Authorization
Verifies user identity	Controls access permissions
Answers: Who are you?	Answers: What can you access?
Example: User login	Example: API permission checking

What is OAuth 2.0?

OAuth 2.0 is an industry-standard authorization framework that allows applications to access protected resources without sharing user passwords.

Instead of giving an application direct access to credentials, OAuth uses secure tokens that represent granted permissions.

Example Scenario

A user wants a photo application to access images stored in another service. The photo application does not receive the user's password. Instead, it receives a limited access token with specific permissions.

OAuth 2.0 Core Components

OAuth 2.0 defines several important roles that work together during the authorization process.

• Resource Owner
• Client Application
• Authorization Server
• Resource Server
• Access Token

Resource Owner

The resource owner is the user who owns protected information or resources.

For example, a customer who owns profile data inside an application.

Client Application

The client is the application requesting access to protected resources.

Examples include:

• Web applications
• Mobile applications
• Single Page Applications
• Backend services

Authorization Server

The authorization server authenticates users and issues security tokens after successful authorization.

Examples include enterprise identity providers and cloud identity platforms.

Resource Server

The resource server hosts protected APIs and validates access tokens before allowing access.

Access Token

An access token is a credential that represents permission to access protected resources.

Applications send access tokens with API requests instead of sending user credentials.

GET /api/orders

Authorization:Bearer eyJhbGciOiJIUzI1...

OAuth 2.0 Authorization Code Flow

The Authorization Code Flow is the most commonly used OAuth 2.0 flow for web applications. It provides strong security by exchanging a temporary authorization code for an access token.

This flow is recommended for applications that can securely store client credentials.

Authorization Code Flow Steps

1. User opens application
2. Application redirects user to Authorization Server
3. User authenticates and grants permission
4. Authorization Server returns authorization code
5. Application exchanges code for access token
6. Application calls protected API

Authorization Request Example

GET /authorize?
client_id=my-client
response_type=code
redirect_uri=https://app.com/callback
scope=profile email

Token Exchange Example

POST /token
grant_type=authorization_code
code=authorization_code_value
client_id=my-client
client_secret=my-secret

OAuth 2.0 Client Credentials Flow

The Client Credentials Flow is used when an application needs to communicate with another service without user interaction.

This is commonly used for backend services, microservices, and machine-to-machine communication.

Example Scenario

An order processing service needs to access a payment service API. No user is involved, so the service authenticates using its own credentials.

Service A -> Client Credentials -> Authorization Server -> Access Token -> Service B API

OAuth 2.0 Device Authorization Flow

Device Authorization Flow is designed for devices that have limited input capabilities such as smart TVs, gaming consoles, and IoT devices.

Device Flow Example

Device displays code -> User opens verification page -> User signs in -> Device receives token

Refresh Tokens in OAuth 2.0

Access tokens usually have a limited lifetime. Refresh tokens allow applications to obtain new access tokens without forcing users to authenticate again.

Refresh Token Flow

Application -> Refresh Token -> Authorization Server -> New Access Token

Refresh Token Request

POST /token

grant_type=refresh_token
refresh_token=token_value
client_id=my-client

OAuth 2.0 Scopes

Scopes define what permissions an application receives when accessing a resource.

Instead of granting complete access, applications request only the permissions they actually need.

Example Scopes

• profile.read
• email.read
• orders.read
• orders.write
• payments.process

Scope Example in Authorization Request

scope=profile.read orders.read

What is OpenID Connect?

OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0. While OAuth 2.0 provides authorization, OpenID Connect adds authentication features.

OIDC allows applications to verify user identity and obtain basic profile information.

Why OpenID Connect Was Created

OAuth 2.0 was originally designed for granting access to resources. It did not define a standard way to authenticate users.

OpenID Connect solves this problem by introducing standardized identity tokens and user information endpoints.

OAuth 2.0 vs OpenID Connect

OAuth 2.0	OpenID Connect
Authorization framework	Authentication protocol
Provides access tokens	Provides ID tokens
Controls resource access	Verifies user identity
Used for API permissions	Used for user login

OpenID Connect Core Components

• Identity Provider
• Client Application
• ID Token
• UserInfo Endpoint
• Claims

Identity Provider (OpenID Provider)

The Identity Provider authenticates users and issues identity information to applications.

It manages:

• User accounts
• Authentication methods
• Security policies
• Identity tokens

ID Token Explained

An ID Token is a security token that contains information about an authenticated user.

It is usually formatted as a JWT containing identity claims.

Example ID Token Payload

{

"sub":"123456",
"name":"John Smith",
"email":"john@example.com",
"iss":"https://identity-provider.com"

}

UserInfo Endpoint

OpenID Connect providers expose a UserInfo endpoint that allows applications to retrieve additional user profile information.

GET /userinfo


Authorization:
Bearer access_token

The endpoint returns user claims such as name, email, and profile information.

OpenID Connect Authentication Flow

OpenID Connect uses OAuth 2.0 authorization flows with additional identity information. The most common approach is the Authorization Code Flow with OpenID Connect scopes.

OIDC Authentication Steps

User -> ASP.NET Core Application -> Identity Provider -> Authorization Code -> ID Token + Access Token -> Authenticated Application

OpenID Connect Scopes

OpenID Connect defines standard scopes that allow applications to request user identity information.

• openid
• profile
• email
• address
• phone

The openid scope is required because it indicates that the application wants authentication information.

ASP.NET Core OAuth Integration

ASP.NET Core provides built-in authentication middleware that makes integration with OAuth 2.0 and OpenID Connect providers easier.

Applications can connect with identity providers such as:

• Microsoft Identity Platform
• Google Identity Services
• Enterprise Identity Providers
• Custom OpenID Connect Servers

Installing Authentication Package

dotnet add package Microsoft.AspNetCore.Authentication.OpenIdConnect

Configuring OpenID Connect in ASP.NET Core

Authentication services are configured inside the ASP.NET Core application startup process.

Program.cs Configuration Example

builder.Services
.AddAuthentication(options =>
{

options.DefaultScheme = "Cookies";
options.DefaultChallengeScheme = "oidc";

})

.AddCookie()

.AddOpenIdConnect("oidc", options =>
{

options.Authority = "https://identity-provider.com";
options.ClientId = "application-client-id";
options.ClientSecret = "application-secret";
options.ResponseType = "code";
options.SaveTokens = true;

});

This configuration enables ASP.NET Core to redirect users to the identity provider and process authentication responses.

Microsoft Identity Platform Integration

Many enterprise applications use Microsoft identity services for authentication, especially when integrating with organizational accounts.

Configuration Example

.AddOpenIdConnect(options =>
{

options.Authority = "https://login.microsoftonline.com/tenant-id";
options.ClientId = "client-id";
options.ClientSecret = "client-secret";
options.ResponseType = "code";

});

Google Login Integration with ASP.NET Core

ASP.NET Core also supports external login providers such as Google.

Adding Google Authentication

builder.Services
.AddAuthentication()

.AddGoogle(options =>
{

options.ClientId = "google-client-id";
options.ClientSecret = "google-client-secret";

});

JWT Tokens in OAuth 2.0 Applications

Modern APIs commonly use JSON Web Tokens (JWT) as access tokens.

A JWT contains information that allows APIs to validate requests without storing session information on the server.

JWT Structure

Header.Payload.Signature

JWT Example Payload

{

"sub":"user123",
"name":"David",
"role":"Admin",
"exp":1720000000

}

Securing ASP.NET Core APIs with JWT Authentication

ASP.NET Core APIs can validate incoming JWT access tokens using authentication middleware.

JWT Authentication Configuration

builder.Services

.AddAuthentication("Bearer")

.AddJwtBearer(options =>
{

options.Authority = "https://identity-provider.com";
options.Audience = "api-resource";

});

Protecting API Controllers

The Authorize attribute ensures that only authenticated users can access protected endpoints.

[ApiController]

[Route("api/orders")]

[Authorize]

public class OrdersController : ControllerBase

{

[HttpGet]

public IActionResult GetOrders()
{

	return Ok();

}

}

Claims in OAuth 2.0 and OpenID Connect

Claims are pieces of information about users or applications included inside security tokens.

Common claims include:

• User identifier
• Email address
• Username
• Roles
• Permissions
• Tenant information

Claims Mapping in ASP.NET Core

Applications can map token claims into ASP.NET Core user identities.

options.TokenValidationParameters = new TokenValidationParameters

{

NameClaimType = "name",
RoleClaimType = "role"

};

Role-Based Authorization

OAuth and OpenID Connect tokens can contain role information that can be used for authorization decisions.

Role Authorization Example

[Authorize(Roles="Admin")]
public IActionResult ManageUsers()
{
	return View();
}

Permission-Based Authorization

Large applications often use permissions instead of simple roles because they provide more flexibility.

[Authorize(Policy="Order.Read")]
public IActionResult GetOrders()
{

	return Ok();

}

OAuth 2.0 & OpenID Connect Security Best Practices

Identity protocols provide powerful security capabilities, but incorrect implementation can introduce security risks. Following recommended practices helps protect applications and user data.

1. Use Authorization Code Flow with PKCE

Proof Key for Code Exchange (PKCE) adds an additional security layer to the Authorization Code Flow by preventing authorization code interception attacks.

PKCE is especially important for:

• Single Page Applications
• Mobile applications
• Public clients without secure secrets

2. Never Store Access Tokens Insecurely

Access tokens should be protected because anyone who obtains a valid token may be able to access protected resources.

• Avoid storing tokens in unsafe browser storage
• Use secure cookies where appropriate
• Protect server-side token storage
• Use short token expiration times

3. Validate JWT Tokens Properly

APIs should always validate:

• Token signature
• Issuer information
• Audience value
• Expiration time
• Required claims

4. Use HTTPS Everywhere

OAuth and OpenID Connect depend on secure communication. All authentication requests and token exchanges should use HTTPS.

5. Request Minimum Required Permissions

Applications should follow the principle of least privilege by requesting only the scopes they actually need.

OAuth 2.0 Token Security

Tokens are the foundation of OAuth-based security. Proper token management is essential for protecting applications.

Access Token Recommendations

• Use short expiration periods
• Use HTTPS communication
• Validate tokens on APIs
• Avoid exposing tokens unnecessarily
• Rotate secrets regularly

OAuth 2.0 and Microservices Architecture

Modern enterprise applications often use microservices where multiple APIs communicate with each other.

OAuth 2.0 provides a consistent security model for protecting these services.

Microservices Authentication Flow

Client Application -> Identity Provider -> Access Token -> API Gateway -> Microservices

Enterprise Identity Architecture

Large organizations usually separate identity management from application business logic.

Common OAuth 2.0 and OpenID Connect Mistakes

• Using password sharing instead of token-based authorization
• Using deprecated authentication flows
• Ignoring token expiration validation
• Allowing excessive permissions
• Storing secrets in source code
• Skipping HTTPS configuration
• Not validating issuer and audience claims
• Using long-lived access tokens

OAuth 2.0 & OpenID Connect Implementation Checklist

• Choose the correct OAuth flow
• Use OpenID Connect for user authentication
• Protect tokens properly
• Enable HTTPS
• Validate JWT tokens
• Use PKCE for public clients
• Configure proper scopes
• Implement role and permission authorization
• Monitor authentication activity
• Regularly review identity provider settings

Frequently Asked Questions About OAuth 2.0 & OpenID Connect

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is an authorization framework used to grant access to resources. OpenID Connect extends OAuth 2.0 by adding authentication and user identity information.

Is OAuth 2.0 an authentication protocol?

No. OAuth 2.0 is primarily designed for authorization. OpenID Connect adds the authentication capabilities required for user login scenarios.

What is an ID Token?

An ID Token is a JWT issued by an OpenID Connect provider that contains information about an authenticated user.

Can OAuth 2.0 be used with ASP.NET Core?

Yes. ASP.NET Core provides built-in authentication middleware for integrating with OAuth 2.0 and OpenID Connect identity providers.

Why are JWT tokens commonly used with OAuth?

JWT tokens provide a compact and secure way for applications and APIs to exchange identity and authorization information.

Conclusion

OAuth 2.0 and OpenID Connect have become essential technologies for building secure modern applications. They provide standardized approaches for user authentication, API authorization, and identity management.

By using OAuth 2.0 for authorization and OpenID Connect for authentication, developers can build secure applications that support web, mobile, API, and enterprise scenarios.

When combined with ASP.NET Core security features, JWT validation, proper token management, and identity best practices, organizations can create scalable and secure software solutions.