Introduction
APIs are the backbone of modern applications. Mobile apps, web applications, microservices, SaaS platforms, and third-party integrations all rely heavily on APIs for communication and data exchange. As API usage grows, securing these endpoints becomes increasingly important.
Traditional authentication methods such as API keys and basic authentication are no longer sufficient for many modern applications. Organizations need stronger authentication and authorization mechanisms that support scalability, delegated access, user identity verification, and modern security practices.
OAuth 2.1 and OpenID Connect (OIDC) have emerged as the industry standards for securing APIs and managing user authentication. Together, they provide a secure and flexible framework for protecting resources while delivering seamless user experiences.
In this article, you'll learn how OAuth 2.1 and OpenID Connect work, their key components, implementation approaches, and best practices for securing APIs.
Understanding OAuth 2.1
OAuth is an authorization framework that allows applications to access resources on behalf of users without exposing user credentials.
Instead of sharing usernames and passwords, applications receive access tokens that grant limited permissions.
OAuth 2.1 builds upon OAuth 2.0 by incorporating modern security recommendations and removing insecure legacy flows.
Its primary goals include:
OAuth focuses on authorization rather than authentication.
Understanding OpenID Connect
OpenID Connect is an identity layer built on top of OAuth.
While OAuth answers:
What can this application access?
OpenID Connect answers:
Who is the user?
OIDC provides:
User authentication
Identity information
Single Sign-On (SSO)
User profile claims
Applications commonly use OAuth and OpenID Connect together.
Why OAuth 2.1 and OIDC Matter
Modern applications require:
OAuth 2.1 and OpenID Connect provide a standardized approach for achieving these goals.
Benefits include:
Strong security
Better user experience
Industry-standard protocols
Reduced credential exposure
Simplified identity management
Key Components of OAuth
Several components work together during authentication and authorization.
Resource Owner
The user who owns the protected data.
Example:
John Smith
Client Application
The application requesting access.
Examples:
Web applications
Mobile apps
Desktop applications
Authorization Server
Responsible for authenticating users and issuing tokens.
Examples include:
Microsoft Entra ID
Auth0
Okta
Keycloak
IdentityServer
Resource Server
The API containing protected resources.
Example:
Customer API
OAuth 2.1 Authorization Flow
The most commonly used flow is Authorization Code Flow with PKCE.
Step 1: User Requests Access
The application redirects the user to the authorization server.
Example:
https://auth.example.com/authorize
Step 2: User Authenticates
The user signs in using credentials, passkeys, MFA, or other supported methods.
Step 3: Authorization Code Issued
The authorization server returns an authorization code.
Step 4: Access Token Exchange
The application exchanges the authorization code for an access token.
Step 5: API Access
The access token is used to call protected APIs.
This flow minimizes security risks and protects user credentials.
What Is PKCE?
PKCE (Proof Key for Code Exchange) is a security enhancement required by OAuth 2.1.
It protects against authorization code interception attacks.
The client generates:
Code Verifier
Code Challenge
Example:
Code Verifier:
random-secret-string
The authorization server validates the verifier during token exchange.
PKCE is particularly important for:
Mobile applications
Single-page applications
Public clients
Understanding Access Tokens
Access tokens represent granted permissions.
Example JWT payload:
{
"sub": "12345",
"name": "John Smith",
"scope": "api.read"
}
Tokens typically contain:
User identifier
Permissions
Expiration information
Issuer information
APIs validate these tokens before granting access.
Understanding ID Tokens
OpenID Connect introduces ID Tokens.
Example:
{
"sub": "12345",
"name": "John Smith",
"email": "[email protected]"
}
ID Tokens provide identity information about authenticated users.
Applications use them to:
Display user information
Create sessions
Implement Single Sign-On
Securing ASP.NET Core APIs
ASP.NET Core provides built-in support for OAuth and OpenID Connect.
Install authentication packages:
dotnet add package
Microsoft.AspNetCore.Authentication.JwtBearer
Configure authentication:
builder.Services
.AddAuthentication("Bearer")
.AddJwtBearer(options =>
{
options.Authority =
"https://auth.example.com";
options.Audience =
"api";
});
Enable middleware:
app.UseAuthentication();
app.UseAuthorization();
This ensures requests are validated before accessing protected resources.
Protecting API Endpoints
Use authorization attributes to secure controllers.
Example:
[Authorize]
[HttpGet]
public IActionResult GetOrders()
{
return Ok();
}
Only authenticated users can access the endpoint.
Role-based authorization:
[Authorize(Roles = "Admin")]
Claim-based authorization:
[Authorize(Policy = "CanManageOrders")]
This enables fine-grained access control.
Implementing OpenID Connect Login
For web applications:
builder.Services
.AddAuthentication(options =>
{
})
.AddCookie()
.AddOpenIdConnect(options =>
{
options.Authority =
"https://auth.example.com";
options.ClientId =
"web-app";
options.ResponseType =
"code";
});
This enables secure user authentication using OpenID Connect.
Refresh Tokens
Access tokens are intentionally short-lived.
Refresh tokens allow applications to obtain new access tokens without requiring users to sign in repeatedly.
Benefits include:
Better user experience
Reduced login prompts
Improved security
Refresh tokens should be protected carefully.
API Security Best Practices
Securing APIs requires more than token validation.
Important practices include:
Use HTTPS Everywhere
Never transmit tokens over unsecured connections.
Validate Tokens Properly
Always verify:
Signature
Issuer
Audience
Expiration
Apply Least Privilege
Grant only the permissions required.
Example:
api.read
Instead of:
admin.fullaccess
Implement Rate Limiting
Protect APIs against abuse and denial-of-service attacks.
Use Short-Lived Access Tokens
Reduce exposure if tokens are compromised.
Monitor Authentication Events
Track:
Failed logins
Suspicious activity
Token misuse
Common OAuth Mistakes
Avoid these common implementation issues:
Storing tokens in insecure locations.
Using implicit flow.
Skipping PKCE.
Not validating JWT signatures.
Granting excessive permissions.
Exposing client secrets.
Using long-lived access tokens.
These mistakes can introduce significant security vulnerabilities.
Practical Example
Consider an e-commerce platform.
Components:
React Frontend
↓
Identity Provider
↓
ASP.NET Core API
↓
Database
Workflow:
User signs in.
Identity provider issues tokens.
Frontend sends access token.
API validates token.
Authorized requests access resources.
This architecture supports secure authentication and authorization at scale.
OAuth 2.1 vs API Keys
| Feature | OAuth 2.1 | API Keys |
|---|
| User Identity | Yes | No |
| Authorization Scopes | Yes | Limited |
| Token Expiration | Yes | Usually No |
| Delegated Access | Yes | No |
| Security | High | Moderate |
| Enterprise Support | Excellent | Limited |
For most enterprise applications, OAuth provides a significantly stronger security model.
Best Practices
When implementing OAuth 2.1 and OpenID Connect:
Use Authorization Code Flow with PKCE.
Validate all tokens.
Enforce HTTPS.
Use short-lived access tokens.
Protect refresh tokens.
Implement role-based authorization.
Monitor authentication events.
Rotate secrets regularly.
Apply least-privilege principles.
Keep identity providers updated.
These practices help create secure and maintainable authentication systems.
Conclusion
OAuth 2.1 and OpenID Connect have become the foundation of modern API security. Together, they provide secure authentication, delegated authorization, user identity management, and support for web, mobile, and enterprise applications.
ASP.NET Core offers excellent support for implementing these standards, making it easier for developers to secure APIs without building authentication systems from scratch. By understanding authorization flows, token management, PKCE, and security best practices, developers can create APIs that are scalable, secure, and ready for modern application architectures.
As organizations continue adopting cloud-native applications and distributed systems, OAuth 2.1 and OpenID Connect remain essential technologies for protecting users, services, and sensitive data.