DEV Community: harshvardhan

Building an Authentication Service in Angular with Signals, JWT & Refresh Tokens

harshvardhan — Wed, 02 Sep 2026 02:52:54 +0000

Authentication is one of the most common requirements in modern web applications.

When building an Angular frontend with an ASP.NET Core Web API, we need a way to:

Login users
Register users
Logout users
Store authentication information
Restore authentication after page refresh
Refresh expired access tokens
Check whether a user is authenticated
Read information from a JWT
Determine the user's role

In this article, I'll walk through the AuthService I use in Angular and explain how each part works.

Creating the Authentication Service

The authentication logic is kept inside a dedicated Angular service.

Instead of making HTTP requests directly from components, components communicate with AuthService.

This keeps authentication logic centralized and prevents different components from implementing their own authentication logic.

Injecting HttpClient

The first dependency is Angular's HttpClient.

http = inject(HttpClient);

Managing the Current User with Signals

One of the most useful parts of this service is the signal used to store the authentication state.

currentUserSignal = signal(null);

The signal initially contains:

null

because no user is authenticated when the application starts.

After successful login, it contains the authentication response.

For example:

{
accessToken: "...",
refreshToken: "..."
}

The signal provides a reactive way of tracking authentication state.

Exposing a Readonly Signal

I don't want other components to directly modify the authentication signal.

Therefore, I expose a readonly version:

public currentUser = this.currentUserSignal.asReadonly();

Now components can read the authentication state:

authService.currentUser()

but they cannot do:

authService.currentUser.set(...)

This is important because the authentication service should remain responsible for changing authentication state.

The login method sends the user's credentials to the backend.

The loginDto might look like:

interface loginDto {
email: string;
password: string;
}

And the backend returns an authentication response:

interface authResponse {
accessToken: string;
refreshToken: string;
}

The important thing here is that the service doesn't subscribe to the HTTP request.

It simply returns the observable.

The component can then decide what to do with the response.

For example:

this.authService.login(this.form.value).subscribe({
next: (response) => {
this.authService.setUser(response);
}
});

Why Return the Observable?

A common mistake is subscribing inside the service:

this.http.post(...).subscribe(response => {
    // ...
});

}

This makes the service responsible for the subscription and makes it harder for components to react to success or failure.

Instead, returning the observable:

return this.http.post(...);

allows the caller to decide how to handle it.

This gives us more flexibility.

Storing Authentication Information

After successful login, I use:

setUser(data: authResponse) {
localStorage.setItem(
'auth',
JSON.stringify(data)
);

this.currentUserSignal.set(data);

}

Two things happen here.

First: Store the data
localStorage.setItem(
'auth',
JSON.stringify(data)
);

This allows the authentication information to survive a browser refresh.

Second: Update the signal
this.currentUserSignal.set(data);

This immediately updates Angular's reactive state.

So after login:

Why Use localStorage?

Angular signals only exist in memory.

If the browser page is refreshed:

Signal
↓
Destroyed

The signal goes back to:

null

But localStorage survives page refreshes.

Therefore, we can use localStorage as persistent client-side storage and the signal as the reactive application state.

         localStorage
              │
              │
              ▼
         AuthService
              │
              ▼
          Signal
              │
              ▼
         Components

However, storing JWTs in localStorage has security trade-offs. If an application has an XSS vulnerability, JavaScript running in the page can potentially read localStorage. For higher-security applications, an HTTP-only secure cookie approach can be preferable.

Restoring Authentication After Refresh

Since the signal is reset after a page refresh, we need to restore the stored authentication state.

That's what restoreUser() does:

restoreUser() {
const stored = localStorage.getItem('auth');

if (stored) {
    this.currentUserSignal.set(
        JSON.parse(stored)
    );
}

}

The process is:

Application starts
↓
restoreUser()
↓
Read localStorage
↓
Authentication found?
↓
Yes
↓
Update signal

This method can be called when the application starts.

For example, it can be called from the root component or an application initialization mechanism.

Clearing Authentication During Logout

Logout is the opposite of login.

clearUser() {
localStorage.removeItem('auth');
this.currentUserSignal.set(null);
}

This removes the authentication information from both places:

localStorage
localStorage.removeItem('auth');
Signal
this.currentUserSignal.set(null);

The backend logout request is separate:

logout() {
return this.http.post(
${enviroment.apiUrl}/Auth/Logout,
{}
);
}

A component can first call the backend logout endpoint and then clear the local authentication state.

Checking Authentication Status

Instead of repeatedly checking:

if (this.authService.currentUser() !== null)

I created a helper method:

isAuthenticated() {
return this.currentUser() !== null;
}

Now components and route guards can simply use:

if (this.authService.isAuthenticated()) {
// authenticated
}

This also makes the code easier to read.

Refresh Tokens

JWT authentication commonly uses two tokens:

Access Token
Refresh Token

The access token is short-lived and is sent with API requests.

The refresh token is used to obtain a new access token when the old one expires.

The service contains:

refreshToken() {
const stored = localStorage.getItem('auth');

if (!stored) {
    throw new Error(`auth doesn't exist`);
}

const tokens = JSON.parse(stored);

return this.http.post(
    `${enviroment.apiUrl}/Auth/Refresh`,
    {
        accessToken: tokens.accessToken,
        refreshToken: tokens.refreshToken
    }
);

}

The stored tokens are retrieved:

const stored = localStorage.getItem('auth');

Then parsed:

const tokens = JSON.parse(stored);

Finally, both tokens are sent to the backend:

{
accessToken: tokens.accessToken,
refreshToken: tokens.refreshToken
}

The backend validates the refresh token and returns a new authentication response.

How Refresh Token Flow Works

The overall process looks like this:

Angular
│
│ Request with access token
▼
ASP.NET Core API
│
│ Access token expired
▼
401 Unauthorized
│
▼
Angular Interceptor
│
│ Send refresh token
▼
/Auth/Refresh
│
▼
New access token
│
▼
Retry original request

This is normally implemented using an HTTP interceptor.

For example:

API Request
↓
Interceptor
↓
Attach Access Token
↓
API
↓
401?
↓
Refresh Token
↓
Retry Request

This means the user doesn't necessarily have to log in again every time the access token expires.

Decoding the JWT

JWTs contain claims.

For example, a decoded JWT might contain:

{
"nameid": "123",
"unique_name": "John",
"email": "john@example.com",
"role": "Admin"
}

The service provides:

getDecodedToken(): any | null {
const user = this.currentUser();

if (!user) return null;

try {
    return jwtDecode(user.accessToken);
} catch {
    return null;
}

}

The jwtDecode() function decodes the JWT payload.

It is important to understand that decoding a JWT is not the same as validating it.

The Angular application should not trust a decoded token for security decisions on the backend.

The backend must always validate the JWT.

The frontend can use the decoded information for UI purposes such as:

Show Admin Dashboard
Show Employee Menu
Hide Admin Button
Display Username

But actual authorization must be enforced by the API.

Getting the User's Role

Since the role is stored inside the JWT claims, we can create a helper:

getRole(): string | null {
const decoded = this.getDecodedToken();

if (!decoded) return null;

return decoded.role ?? null;

}

Now a component can simply do:

const role = this.authService.getRole();

For example:

if (this.authService.getRole() === 'Admin') {
// show admin UI
}

This becomes particularly useful when implementing role-based navigation.

Example Role-Based UI

For example:

const role = this.authService.getRole();

if (role === 'Admin') {
// Admin navigation
}

if (role === 'Employee') {
// Employee navigation
}

if (role === 'Customer') {
// Customer navigation
}

However, this should only control the frontend experience.

The backend should still protect the endpoint:

[Authorize(Roles = "Admin")]
[HttpGet("users")]
public async Task GetUsers()
{
// ...
}

This gives us two layers:

Frontend
↓
Better user experience
↓
Hide/show UI

Backend
↓
Actual security
↓
Authorize requests

Never rely on Angular alone for authorization.

The Complete AuthService

Putting everything together:

import { HttpClient } from '@angular/common/http';
import { inject, Injectable, signal } from '@angular/core';
import { jwtDecode } from 'jwt-decode';

@Injectable({
providedIn: 'root'
})
export class AuthService {

http = inject(HttpClient);

currentUserSignal =
    signal<authResponse | null>(null);

public currentUser =
    this.currentUserSignal.asReadonly();


login(data: loginDto) {
    return this.http.post<authResponse>(
        `${enviroment.apiUrl}/Auth/Login`,
        data
    );
}


logout() {
    return this.http.post(
        `${enviroment.apiUrl}/Auth/Logout`,
        {}
    );
}


register(data: registerDto) {
    return this.http.post<authResponse>(
        `${enviroment.apiUrl}/Auth/Register`,
        data
    );
}


refreshToken() {

    const stored =
        localStorage.getItem('auth');

    if (!stored) {
        throw new Error('auth doesn\'t exist');
    }

    const tokens = JSON.parse(stored);

    return this.http.post(
        `${enviroment.apiUrl}/Auth/Refresh`,
        {
            accessToken: tokens.accessToken,
            refreshToken: tokens.refreshToken
        }
    );
}


restoreUser() {

    const stored =
        localStorage.getItem('auth');

    if (stored) {
        this.currentUserSignal.set(
            JSON.parse(stored)
        );
    }
}


setUser(data: authResponse) {

    localStorage.setItem(
        'auth',
        JSON.stringify(data)
    );

    this.currentUserSignal.set(data);
}


clearUser() {

    localStorage.removeItem('auth');

    this.currentUserSignal.set(null);
}


isAuthenticated() {

    return this.currentUser() !== null;
}


getDecodedToken(): any | null {

    const user = this.currentUser();

    if (!user) return null;

    try {
        return jwtDecode(user.accessToken);
    }
    catch {
        return null;
    }
}


getRole(): string | null {

    const decoded =
        this.getDecodedToken();

    if (!decoded) return null;

    return decoded.role ?? null;
}

}

Authentication State Architecture

The most important concept in this service is that there are two layers of state.

Persistent state
localStorage

This survives browser refreshes.

Reactive state
Angular Signal

This is a simple but effective pattern for managing authentication state in Angular.

What I Like About This Approach

There are several advantages to keeping authentication inside one service.

Centralized Authentication

Signals make it easy for Angular components to react to authentication changes.

Separation of Responsibilities

Components don't need to know how tokens are stored.

They simply interact with:

authService.login(...)
authService.logout(...)
authService.currentUser()
authService.isAuthenticated()
authService.getRole()
Easy to Extend

Additional functionality can be added later, such as:

getUserId()
getEmail()
getUsername()
hasRole()
hasAnyRole()
isTokenExpired()

Important Security Considerations

This implementation is useful for learning and many applications, but authentication requires careful security considerations.


 http = inject(HttpClient);
  currentUserSignal = signal<authResponse | null>(null);
  public currentUser = this.currentUserSignal.asReadonly();

  login(data: loginDto) {
    return this.http.post<authResponse>(`${enviroment.apiUrl}/Auth/Login`, data);
  }

  logout() {
    return this.http.post(`${enviroment.apiUrl}/Auth/Logout`, {});
  }

  register(data: registerDto) {
    return this.http.post<authResponse>(`${enviroment.apiUrl}/Auth/Register`, data);
  }

  refreshToken() {
    const stored = localStorage.getItem('auth');

    if (!stored) {
      throw new Error(`auth doesn't exist`);
    }

    const tokens = JSON.parse(stored);

    return this.http.post(`${enviroment.apiUrl}/Auth/Refresh`, {
      accessToken: tokens.accessToken,
      refreshToken: tokens.refreshToken,
    });
  }

  restoreUser() {
    const stored = localStorage.getItem('auth');
    if (stored) {
      this.currentUserSignal.set(JSON.parse(stored));
    }
  }

  setUser(data: authResponse) {
    localStorage.setItem('auth', JSON.stringify(data));
    this.currentUserSignal.set(data);
  }

  clearUser() {
    localStorage.removeItem('auth');
    this.currentUserSignal.set(null);
  }

  isAuthenticated() {
    return this.currentUser() !== null;
  }

  getDecodedToken(): any | null {
    const user = this.currentUser();
    if (!user) return null;
    try {
      return jwtDecode(user.accessToken);
    } catch {
      return null;
    }
  }

  getRole(): string | null {
    const decoded = this.getDecodedToken();
    if (!decoded) return null;
    return decoded.role ?? null;
  }

Setting Up a Production-Ready ASP.NET Core Web API: JWT, Identity, CQRS, Validation, Exception Handling & CORS

harshvardhan — Tue, 01 Sep 2026 16:35:14 +0000

When building an ASP.NET Core Web API, Program.cs can quickly become the central place where everything comes together.

Database configuration, dependency injection, authentication, authorization, CQRS, validation, exception handling, CORS, Swagger, and application middleware all need to be configured correctly.

In this article, I'll walk through how I configured these pieces in an ASP.NET Core Web API using Entity Framework Core, ASP.NET Identity, JWT authentication, MediatR, FluentValidation, and Clean Architecture concepts.

1. Creating the WebApplication Builder

The first step is creating the application builder:

var builder = WebApplication.CreateBuilder(args);

WebApplication.CreateBuilder() initializes the application and provides access to:

Configuration
Dependency Injection
Logging
Environment information
Application services

The builder.Services collection is where we register the services our application needs.

2. Adding Controllers

builder.Services.AddControllers();

This registers ASP.NET Core MVC controllers with the dependency injection container.

For example:

[ApiController]
[Route("api/[controller]")]
public class AuthController : ControllerBase
{
    // endpoints
}

Without AddControllers(), ASP.NET Core won't be able to discover and use controller-based API endpoints.

Later, we map these controllers using:

app.MapControllers();

3. Global Exception Handling

Instead of handling exceptions individually inside every controller or handler, I use a global exception handler.

builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
builder.Services.AddProblemDetails();

The GlobalExceptionHandler is responsible for catching unhandled exceptions and converting them into appropriate HTTP responses.

This gives the API a consistent error format.

For example, instead of writing:

try
{
    // logic
}
catch(Exception ex)
{
    // handle exception
}

inside every controller, exceptions can be handled centrally.

The middleware is then enabled with:

app.UseExceptionHandler();

This keeps controllers and handlers much cleaner.

4. Configuring Entity Framework Core

The application uses SQL Server as its database.

First, the connection string is retrieved from configuration:

string connectionString =
    builder.Configuration.GetConnectionString("default");

Then the AppDbContext is registered:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

This allows Entity Framework Core to inject AppDbContext wherever it is required.

For example:

public class LoginCommandHandler
{
    private readonly AppDbContext _context;

    public LoginCommandHandler(AppDbContext context)
    {
        _context = context;
    }
}

The connection string itself should normally be stored in appsettings.json or another configuration provider rather than being hardcoded.

Example:

{
  "ConnectionStrings": {
    "default": "Server=.;Database=MyDatabase;Trusted_Connection=True;TrustServerCertificate=True"
  }
}

5. Registering MediatR

For CQRS, I use MediatR to separate commands and queries from the controllers.

builder.Services.AddMediatR(cfg =>
    cfg.RegisterServicesFromAssembly(
        typeof(LoginCommandHandler).Assembly));

This tells MediatR to scan the assembly containing LoginCommandHandler and automatically register the handlers it finds.

For example:

public record LoginCommand(
    string Email,
    string Password
) : IRequest<LoginResponse>;

The corresponding handler can be:

public class LoginCommandHandler
    : IRequestHandler<LoginCommand, LoginResponse>
{
    public async Task<LoginResponse> Handle(
        LoginCommand request,
        CancellationToken cancellationToken)
    {
        // login logic
    }
}

The controller doesn't need to know how the login operation is implemented.

It simply sends the command:

await _mediator.Send(command);

This is one of the main benefits of using CQRS with MediatR.

6. Adding FluentValidation

Validation is another responsibility that I prefer to keep separate from controllers.

builder.Services.AddValidatorsFromAssembly(
    typeof(LoginCommand).Assembly);

This searches the assembly for FluentValidation validators.

For example:

public class LoginCommandValidator
    : AbstractValidator<LoginCommand>
{
    public LoginCommandValidator()
    {
        RuleFor(x => x.Email)
            .NotEmpty()
            .EmailAddress();

        RuleFor(x => x.Password)
            .NotEmpty()
            .MinimumLength(6);
    }
}

Now validation rules are separated from the command itself.

7. Validation Pipeline Behavior

Simply registering validators isn't enough if we want validation to happen automatically before the handler executes.

For that, I use a MediatR pipeline behavior:

builder.Services.AddTransient(
    typeof(IPipelineBehavior<,>),
    typeof(ValidationBehavior<,>));

The pipeline works roughly like this:

Controller
    ↓
MediatR
    ↓
ValidationBehavior
    ↓
Validator
    ↓
Command Handler

If validation fails, the handler doesn't need to execute.

This keeps business logic free from repetitive validation checks.

8. Configuring ASP.NET Identity

For authentication and user management, I use ASP.NET Core Identity.

builder.Services
    .AddIdentity<ApplicationUser, IdentityRole<Guid>>()
    .AddEntityFrameworkStores<AppDbContext>()
    .AddDefaultTokenProviders();

Here:

ApplicationUser represents our custom user entity.
IdentityRole<Guid> represents application roles.
AppDbContext stores Identity data in SQL Server.
AddDefaultTokenProviders() enables built-in token providers.

Because the application uses Guid as the key type, roles and users are configured with Guid.

A custom user can look like:

public class ApplicationUser : IdentityUser<Guid>
{
    public string FullName { get; set; }
}

This allows us to extend the default Identity user with application-specific properties.

9. JWT Authentication

ASP.NET Identity handles user management, but for API authentication I use JWT bearer tokens.

First, the authentication scheme is configured:

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme =
        JwtBearerDefaults.AuthenticationScheme;

    options.DefaultChallengeScheme =
        JwtBearerDefaults.AuthenticationScheme;

    options.DefaultScheme =
        JwtBearerDefaults.AuthenticationScheme;
})

Then JWT authentication is added:

.AddJwtBearer(options =>
{
    options.SaveToken = true;
    options.RequireHttpsMetadata = false;

    options.TokenValidationParameters =
        new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,

            ValidAudience =
                builder.Configuration["JWT:ValidAudience"],

            ValidIssuer =
                builder.Configuration["JWT:ValidIssuer"],

            ClockSkew = TimeSpan.Zero,

            IssuerSigningKey =
                new SymmetricSecurityKey(
                    Encoding.UTF8.GetBytes(
                        builder.Configuration["JWT:secret"]))
        };
});

When a client sends a request with:

Authorization: Bearer <token>

ASP.NET Core validates the JWT.

Several things are checked here.

Issuer

ValidateIssuer = true

The API verifies that the token was issued by the expected issuer.

Audience

ValidateAudience = true

The token must be intended for the configured API audience.

Signing Key

IssuerSigningKey =
    new SymmetricSecurityKey(...)

This key is used to verify that the token hasn't been modified.

Clock Skew

ClockSkew = TimeSpan.Zero

This removes the default time tolerance during token expiration validation.

For production applications, secrets should be stored securely using environment variables, secret managers, or another secure configuration mechanism rather than committing them directly to source control.

10. Configuring CORS

Since my frontend is running separately from the API, I need to configure Cross-Origin Resource Sharing.

builder.Services.AddCors(options =>
    options.AddPolicy("AngularPolicy", policy =>
    {
        policy
            .WithOrigins("http://localhost:4200")
            .AllowAnyHeader()
            .AllowAnyMethod()
            .AllowCredentials();
    })
);

The important part is:

.WithOrigins("http://localhost:4200")

This allows requests from my Angular development server.

I also allow:

.AllowAnyHeader()
.AllowAnyMethod()

which allows HTTP methods such as:

GET
POST
PUT
DELETE

and request headers such as:

Authorization
Content-Type

Finally:

.AllowCredentials();

allows credentials such as cookies or authentication-related browser credentials to be sent.

For production, the allowed origin should be changed from localhost to the actual frontend domain.

11. Registering Application Services

Next, I register the services used by the application.

builder.Services.AddScoped<ITokenService, TokenService>();
builder.Services.AddScoped<IAuthService, AuthService>();
builder.Services.AddScoped<IAdminService, AdminService>();
builder.Services.AddScoped<ICurrentUser, CurrentUser>();
builder.Services.AddScoped<IEmailService, EmailService>();

This follows the Dependency Inversion Principle.

For example, instead of depending directly on:

TokenService

other parts of the application depend on:

ITokenService

The implementation can then be injected automatically.

public class AuthService : IAuthService
{
    private readonly ITokenService _tokenService;

    public AuthService(ITokenService tokenService)
    {
        _tokenService = tokenService;
    }
}

Using interfaces makes services easier to replace, test, and maintain.

12. Understanding Scoped Lifetime

Most application services above are registered using:

AddScoped()

A scoped service is created once per HTTP request.

For example:

HTTP Request
     ↓
AuthService instance
     ↓
TokenService instance
     ↓
Database operations
     ↓
HTTP Response

When the request finishes, the scoped services are disposed.

This lifetime is commonly used for services that work with DbContext.

13. Swagger Configuration

Swagger is useful for testing and documenting API endpoints.

First:

builder.Services.AddEndpointsApiExplorer();

Then Swagger is configured:

builder.Services.AddSwaggerGen(option =>
{
    option.AddSecurityDefinition(
        "Bearer",
        new OpenApiSecurityScheme
        {
            Type = SecuritySchemeType.Http,
            Scheme = "Bearer",
            BearerFormat = "JWT",
            Description = "JWT Authentication"
        });

    option.AddSecurityRequirement(document =>
        new OpenApiSecurityRequirement
        {
            [new OpenApiSecuritySchemeReference(
                "Bearer",
                document)] = []
        });
});

The security definition tells Swagger that the API uses Bearer authentication.

After running the application, Swagger provides an interactive interface where we can test endpoints.

For protected endpoints, we can provide the JWT token and make authenticated requests directly from Swagger.

14. Building the Application

After registering all services:

var app = builder.Build();

At this point, the application has been built and we can configure its middleware pipeline.

15. Middleware Pipeline

The middleware order is important.

My pipeline looks like this:

app.UseExceptionHandler();

app.UseSwagger();

app.UseSwaggerUI();

app.UseHttpsRedirection();

app.UseCors("AngularPolicy");

app.UseAuthentication();

app.UseAuthorization();

app.MapControllers();

Let's understand the important parts.

Exception Handler

app.UseExceptionHandler();

This handles unhandled exceptions globally.

Swagger

app.UseSwagger();
app.UseSwaggerUI();

These enable the Swagger JSON endpoint and Swagger UI.

HTTPS Redirection

app.UseHttpsRedirection();

HTTP requests are redirected to HTTPS.

For production applications, HTTPS should generally be used for protecting authentication tokens and other sensitive data in transit.

CORS

app.UseCors("AngularPolicy");

This activates the CORS policy we registered earlier.

Authentication

app.UseAuthentication();

This determines who the current user is.

For JWT authentication, it reads the bearer token and validates it.

Authorization

app.UseAuthorization();

Authentication and authorization are different concepts.

Authentication answers:

Who are you?

Authorization answers:

Are you allowed to perform this operation?

For example:

[Authorize(Roles = "Admin")]

can restrict an endpoint to users with the Admin role.

That's why authentication should run before authorization.

16. Mapping Controllers

Finally:

app.MapControllers();

This maps controller routes to the application's HTTP pipeline.

For example:

[ApiController]
[Route("api/[controller]")]
public class AdminController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok();
    }
}

will become accessible through the configured API route.

17. Seeding Roles and Admin Data

Before starting the application, I also seed initial roles and administrator data:

await RoleSeeder.SeedData(app);

await AdminSeeder.SeedData(app);

This is useful when the application requires predefined roles or an initial administrator account.

For example, the role seeder might create:

Admin
Customer
Employee

if they don't already exist.

The admin seeder can then create the initial administrator account.

This means the application doesn't require manually inserting an administrator into the database every time the database is created.

18. Starting the Application

Finally:

app.Run();

starts the ASP.NET Core application and begins listening for HTTP requests.

Complete Program.cs

Putting everything together:

var builder = WebApplication.CreateBuilder(args);

// Controllers
builder.Services.AddControllers();

// Exception handling
builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
builder.Services.AddProblemDetails();

// Database
string connectionString =
    builder.Configuration.GetConnectionString("default");

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

// MediatR
builder.Services.AddMediatR(cfg =>
    cfg.RegisterServicesFromAssembly(
        typeof(LoginCommandHandler).Assembly));

// FluentValidation
builder.Services.AddValidatorsFromAssembly(
    typeof(LoginCommand).Assembly);

// Validation pipeline
builder.Services.AddTransient(
    typeof(IPipelineBehavior<,>),
    typeof(ValidationBehavior<,>));

// Identity
builder.Services
    .AddIdentity<ApplicationUser, IdentityRole<Guid>>()
    .AddEntityFrameworkStores<AppDbContext>()
    .AddDefaultTokenProviders();

// JWT Authentication
builder.Services
    .AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme =
            JwtBearerDefaults.AuthenticationScheme;

        options.DefaultChallengeScheme =
            JwtBearerDefaults.AuthenticationScheme;

        options.DefaultScheme =
            JwtBearerDefaults.AuthenticationScheme;
    })
    .AddJwtBearer(options =>
    {
        options.SaveToken = true;
        options.RequireHttpsMetadata = false;

        options.TokenValidationParameters =
            new TokenValidationParameters
            {
                ValidateIssuer = true,
                ValidateAudience = true,

                ValidAudience =
                    builder.Configuration["JWT:ValidAudience"],

                ValidIssuer =
                    builder.Configuration["JWT:ValidIssuer"],

                ClockSkew = TimeSpan.Zero,

                IssuerSigningKey =
                    new SymmetricSecurityKey(
                        Encoding.UTF8.GetBytes(
                            builder.Configuration["JWT:secret"]))
            };
    });

// CORS
builder.Services.AddCors(options =>
    options.AddPolicy("AngularPolicy", policy =>
    {
        policy
            .WithOrigins("http://localhost:4200")
            .AllowAnyHeader()
            .AllowAnyMethod()
            .AllowCredentials();
    }));

// Application services
builder.Services.AddScoped<ITokenService, TokenService>();
builder.Services.AddScoped<IAuthService, AuthService>();
builder.Services.AddScoped<IAdminService, AdminService>();
builder.Services.AddScoped<ICurrentUser, CurrentUser>();
builder.Services.AddScoped<IEmailService, EmailService>();

// Swagger
builder.Services.AddEndpointsApiExplorer();

builder.Services.AddSwaggerGen(option =>
{
    option.AddSecurityDefinition(
        "Bearer",
        new OpenApiSecurityScheme
        {
            Type = SecuritySchemeType.Http,
            Scheme = "Bearer",
            BearerFormat = "JWT",
            Description = "JWT Authentication"
        });

    option.AddSecurityRequirement(document =>
        new OpenApiSecurityRequirement
        {
            [new OpenApiSecuritySchemeReference(
                "Bearer",
                document)] = []
        });
});


var app = builder.Build();

// Middleware
app.UseExceptionHandler();

app.UseSwagger();
app.UseSwaggerUI();

app.UseHttpsRedirection();

app.UseCors("AngularPolicy");

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

// Seed initial data
await RoleSeeder.SeedData(app);
await AdminSeeder.SeedData(app);

app.Run();

Implementing JWT Authentication and Refresh Tokens in ASP.NET Core .NET 10

harshvardhan — Sun, 30 Aug 2026 12:53:46 +0000

Let's Understand How It Works

Before we start implementing authentication, let's first understand the basic flow.

When a user logs in, they send their credentials (such as email and password) to the server through a login API. The server validates those credentials and, if they are correct, generates a JWT access token and returns it to the client.

The JWT contains claims that provide information about the authenticated user, such as their user ID, name, email, or role.

Whenever the client wants to access a protected API, it sends the JWT in the Authorization header:

Authorization: Bearer <access-token>

The server then validates the token before allowing the request to access the protected resource.

This gives us the basic authentication flow:

User → Login API → Validate Credentials → Generate JWT → Client → Protected API

Basic authentication flow using JWT

Refresh Token

Access tokens should generally be short-lived. A short lifetime reduces the amount of time an attacker can use a stolen access token.

However, this introduces another problem. If the access token expires after a short period, the user would have to log in again to obtain a new one. Obviously, asking users to enter their credentials repeatedly would not provide a good user experience.

This is where refresh tokens come into the picture.

During login, after validating the user's credentials, the server generates two tokens:

Access Token — short-lived and used to access protected APIs.
Refresh Token — long-lived and used to obtain a new access token.

The client stores both tokens. When the access token expires, instead of asking the user to log in again, the client sends the refresh token to the refresh endpoint.

The server validates the refresh token and, if it is still valid, generates a new access token and a new refresh token.

The process looks like this:

Login → Access Token + Refresh Token

Then, when the access token expires:

Refresh Token → Validate → New Access Token + New Refresh Token

Authentication flow using refresh tokens

This allows us to keep access tokens short-lived while still providing a smooth experience for the user.

Tools and Technologies Used

For this project, I'll be using the following technologies:

Visual Studio / VS Code — Development environment
.NET 10 — Backend framework
ASP.NET Core Web API — Building the REST API
SQL Server — Database
Entity Framework Core — ORM for database operations
ASP.NET Core Identity — User and role management
Swagger — Testing the APIs

Connection String

We'll use SQL Server as the database for this project.

Add the SQL Server connection string to appsettings.json:

"ConnectionStrings": {
  "DefaultConnection": "Server=localhost;Database=JwtAuthDemo;Trusted_Connection=True;TrustServerCertificate=True;"
}

We'll use this connection string later when configuring Entity Framework Core and registering our DbContext.

Models

Let's start by creating the model that represents our application user.

Create a new folder named Models. Inside the Models folder, create a class named ApplicationUser.

We'll inherit from IdentityUser<Guid> instead of the default IdentityUser. This allows ASP.NET Core Identity to use a Guid as the primary key for our users.

public class ApplicationUser : IdentityUser<Guid>
{
    public string Name { get; set; } = string.Empty;

    public string RefreshToken { get; set; } = string.Empty;

    public DateTime RefreshTokenExpiryTime { get; set; }
}

Here, ApplicationUser extends the built-in IdentityUser class and adds the properties that are specific to our application.

Name — stores the user's name.
RefreshToken — stores the currently issued refresh token.
RefreshTokenExpiryTime — stores the expiration time of the refresh token.

ASP.NET Core Identity already provides several properties such as Id, Email, UserName, PasswordHash, and other user-management fields. By extending IdentityUser<Guid>, we can use all of that functionality while adding our own application-specific properties.

ApplicationDbContext

Next, we need to create our Entity Framework Core DbContext.

Create a new class named AppDbContext :

using Microsoft.AspNetCore.Identity;
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;

public class AppDbContext
    : IdentityDbContext<ApplicationUser, IdentityRole<Guid>, Guid>
{
    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options)
    {
    }

    public DbSet<Student> Students { get; set; }

    public DbSet<Course> Courses { get; set; }

    public DbSet<Enrollment> Enrollments { get; set; }

    protected override void OnModelCreating(ModelBuilder builder)
    {
        base.OnModelCreating(builder);

        // Student → Enrollment (One-to-Many)
        builder.Entity<Enrollment>()
            .HasOne(e => e.Student)
            .WithMany(s => s.Enrollments)
            .HasForeignKey(e => e.StudentId);

        // Course → Enrollment (One-to-Many)
        builder.Entity<Enrollment>()
            .HasOne(e => e.Course)
            .WithMany(c => c.Enrollments)
            .HasForeignKey(e => e.CourseId);

        // Seed Courses
        builder.Entity<Course>().HasData(
            new Course {Id = 1, Name = "C# Programming", Credits = 4},
            new Course {Id = 2, Name = "Database Management", Credits=3},
            new Course{Id = 3, Name = "Web Development", Credits = 4}
        );
    }
}

Our AppDbContext inherits from:

IdentityDbContext<ApplicationUser, IdentityRole<Guid>, Guid>

The three generic parameters specify:

ApplicationUser — our custom user entity.
IdentityRole<Guid> — the Identity role entity, using Guid as its primary key.
Guid — the type of the primary key used by Identity.

By inheriting from IdentityDbContext, Entity Framework Core will create and manage the required ASP.NET Core Identity tables, such as users, roles, claims, and user-role relationships.

We can also add our own DbSet properties to this context later if the application contains additional entities.

Registering AppDbContext and Identity

Now, we need to register our AppDbContext and ASP.NET Core Identity in Program.cs.

First, retrieve the connection string from appsettings.json and register the AppDbContext with Entity Framework Core:

string connectionString = builder.Configuration
    .GetConnectionString("DefaultConnection")!;

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

Since we are using ASP.NET Core Identity, we also need to register Identity and tell it to use our AppDbContext for storing Identity data:

builder.Services.AddIdentity<ApplicationUser, IdentityRole<Guid>>()
    .AddEntityFrameworkStores<AppDbContext>()
    .AddDefaultTokenProviders();

Here:

ApplicationUser is our custom Identity user.
IdentityRole<Guid> represents roles and uses Guid as the primary key.
AddEntityFrameworkStores<AppDbContext>() tells Identity to store users, roles, claims, and other Identity-related data using Entity Framework Core.
AddDefaultTokenProviders() registers the default token providers provided by ASP.NET Core Identity.

Finally, we need to add the authentication and authorization middleware to the request pipeline.

Make sure they are added before MapControllers():

app.UseAuthentication();
app.UseAuthorization();

app.MapControllers();

UseAuthentication() is responsible for identifying the user from the provided authentication credentials, such as a JWT.

UseAuthorization() then determines whether the authenticated user has permission to access the requested resource.

The order is important:

Request
   ↓
UseAuthentication()
   ↓
UseAuthorization()
   ↓
MapControllers()
   ↓
Controller

We'll configure JWT authentication shortly. Once that configuration is in place, UseAuthentication() will be responsible for validating the JWT sent with requests to protected endpoints.

JWT Configuration

Now that we have configured Entity Framework Core and ASP.NET Core Identity, the next step is to configure JWT authentication.

We need a few JWT-related settings such as the issuer, audience, and secret key.

Add the following configuration to appsettings.json:

"JWT": {
  "ValidAudience": "https://localhost:7001",
  "ValidIssuer": "https://localhost:7001"
}

Replace https://localhost:7001 with the URL of your API if your application is running on a different port.

ValidAudience

ValidAudience specifies who the JWT is intended for.

This value is used to validate the aud claim in the JWT. When the server receives a token, it can check whether the token was issued for the expected audience.

For example:

{
  "aud": "https://localhost:7001"
}

If the audience in the token doesn't match the configured audience, the token validation will fail.

ValidIssuer

ValidIssuer identifies the application or authentication server that issued the JWT.

This value is used to validate the iss claim in the token.

For example:

{
  "iss": "https://localhost:7001"
}

When validating a token, the application checks whether the issuer matches the configured value.

JWT Secret Key

The JWT also needs a secret key to sign and validate tokens.

For local development, instead of putting the secret directly inside appsettings.json, we'll store it using .NET User Secrets.

First, initialize User Secrets for the project:

dotnet user-secrets init

Then store the JWT secret:

dotnet user-secrets set "JWT:Secret" "your-32-characters-long-super-strong-jwt-secret-key"

The secret should be long, random, and kept private. Never commit your JWT secret to source control.

For production environments, use a proper secret-management solution such as a cloud key vault or another secure secrets manager.

Configuring JWT Authentication

Now let's configure JWT Bearer authentication in Program.cs.

Add the following configuration:

using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;
using System.Text;

builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme =
        JwtBearerDefaults.AuthenticationScheme;

    options.DefaultChallengeScheme =
        JwtBearerDefaults.AuthenticationScheme;

    options.DefaultScheme =
        JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(options =>
{
    options.SaveToken = true;
    options.RequireHttpsMetadata = false;

    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,

        ValidAudience = builder.Configuration["JWT:ValidAudience"],
        ValidIssuer = builder.Configuration["JWT:ValidIssuer"],

        ClockSkew = TimeSpan.Zero,

        IssuerSigningKey = new SymmetricSecurityKey(
            Encoding.UTF8.GetBytes(
                builder.Configuration["JWT:Secret"]!
            )
        )
    };
});

Let's understand some of the important settings.

`ValidateIssuer`

ValidateIssuer = true

This tells ASP.NET Core to validate the iss claim of the JWT against the configured ValidIssuer.

`ValidateAudience`

ValidateAudience = true

This validates the aud claim against the configured ValidAudience.

`ClockSkew`

ClockSkew = TimeSpan.Zero

ClockSkew allows some tolerance when validating token expiration times. Setting it to TimeSpan.Zero means no additional time is added as a tolerance.

`IssuerSigningKey`

IssuerSigningKey = new SymmetricSecurityKey(
    Encoding.UTF8.GetBytes(
        builder.Configuration["JWT:Secret"]!
    )
)

The secret key is converted into a byte array and used to create the symmetric signing key.

This key is important because the same secret is used to validate that the JWT was signed by our application and has not been modified.

At this point, our application knows how to validate JWTs. In the next sections, we'll create the service responsible for generating the access and refresh tokens.

Creating the Database with EF Core Migrations

Now that our AppDbContext, Identity, and JWT configuration are in place, we can create the database using Entity Framework Core migrations.

Open Package Manager Console in Visual Studio:

Tools → NuGet Package Manager → Package Manager Console

Run the following command to create the initial migration:

Add-Migration InitialCreate

This creates a migration containing the changes required to create our database schema, including the tables required by ASP.NET Core Identity.

Next, apply the migration to the SQL Server database:

Update-Database

After running these commands successfully, Entity Framework Core will create the database and the required Identity tables in SQL Server.

You can now open SQL Server Management Studio (SSMS) or SQL Server Object Explorer and verify that the database and Identity tables have been created.

Role Constants

Instead of using role names such as "Admin" and "User" throughout the application, we'll keep them in one place.

Create a folder named Constants. Inside it, create a class named Roles.

// Domain/Constants/Roles.cs

namespace Practice_Backend.Domain.Constants;

public class Roles
{
    public const string Admin = "Admin";
    public const string User = "User";
}

Now, whenever we need to check or assign a role, we can use Roles.Admin or Roles.User instead of hardcoding the role name.

For example:

[Authorize(Roles = Roles.Admin)]

This also makes it easier to change role names later without having to search through the entire application.

Seeding Roles

Our application needs two roles:

Admin
User

Rather than manually creating these roles in the database, we can seed them when the application starts.

Create a folder named Seeder inside the Infrastructure project and create a class named RoleSeeder.

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Practice_Backend.Domain.Constants;

namespace Practice_Backend.Infrastructure.Seeder;

public class RoleSeeder
{
    public static async Task SeedData(IApplicationBuilder app)
    {
        using var scope = app.ApplicationServices.CreateScope();

        var roleManager = scope.ServiceProvider
            .GetRequiredService<RoleManager<IdentityRole<Guid>>>();

        var logger = scope.ServiceProvider
            .GetRequiredService<ILogger<RoleSeeder>>();

        var roles = new[]
        {
            Roles.Admin,
            Roles.User
        };

        foreach (var role in roles)
        {
            if (await roleManager.RoleExistsAsync(role))
            {
                continue;
            }

            var result = await roleManager.CreateAsync(
                new IdentityRole<Guid>(role)
            );

            if (result.Succeeded)
            {
                logger.LogInformation(
                    "Role {Role} created successfully",
                    role
                );
            }
            else
            {
                var errors = result.Errors
                    .Select(e => e.Description);

                logger.LogError(
                    "Failed to create role {Role}. Errors: {Errors}",
                    role,
                    string.Join(", ", errors)
                );
            }
        }
    }
}

The important part here is that we first check whether a role already exists:

if (await roleManager.RoleExistsAsync(role))
{
    continue;
}

This prevents the seeder from trying to create the same role every time the application starts.

Seeding the Admin User

Creating the Admin role is not enough. We also need an administrator account that can be assigned this role.

We'll create a separate AdminSeeder for this purpose.

Create another class named AdminSeeder inside the Seeder folder:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Identity;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;
using Practice_Backend.Domain.Constants;
using Practice_Backend.Domain.Entities;

namespace Practice_Backend.Infrastructure.Seeder;

public class AdminSeeder
{
    public static async Task SeedData(IApplicationBuilder app)
    {
        using var scope = app.ApplicationServices.CreateScope();

        var userManager = scope.ServiceProvider
            .GetRequiredService<UserManager<ApplicationUser>>();

        var logger = scope.ServiceProvider
            .GetRequiredService<ILogger<AdminSeeder>>();

        try
        {
            var admin = await userManager
                .FindByEmailAsync("admin@gmail.com");

            if (admin == null)
            {
                admin = new ApplicationUser
                {
                    Name = "Admin",
                    UserName = "admin@gmail.com",
                    Email = "admin@gmail.com",
                    EmailConfirmed = true,
                    SecurityStamp = Guid.NewGuid().ToString()
                };

                var result = await userManager.CreateAsync(
                    admin,
                    "Admin@123"
                );

                if (!result.Succeeded)
                {
                    var errors = result.Errors
                        .Select(e => e.Description);

                    logger.LogError(
                        "Failed to create admin. Errors: {Errors}",
                        string.Join(", ", errors)
                    );

                    return;
                }

                logger.LogInformation("Admin user created");
            }

            if (!await userManager.IsInRoleAsync(admin, Roles.Admin))
            {
                var result = await userManager.AddToRoleAsync(
                    admin,
                    Roles.Admin
                );

                if (!result.Succeeded)
                {
                    var errors = result.Errors
                        .Select(e => e.Description);

                    logger.LogError(
                        "Failed to assign Admin role. Errors: {Errors}",
                        string.Join(", ", errors)
                    );

                    return;
                }

                logger.LogInformation(
                    "Admin role assigned successfully"
                );
            }
        }
        catch (Exception ex)
        {
            logger.LogCritical(
                ex,
                "Error occurred while seeding admin"
            );
        }
    }
}

There are two important checks in this seeder.

First, we check whether the admin user already exists:

var admin = await userManager
    .FindByEmailAsync("admin@gmail.com");

If the user doesn't exist, we create the account.

After that, we check whether the user already has the Admin role:

if (!await userManager.IsInRoleAsync(admin, Roles.Admin))

If the role hasn't been assigned, we assign it using:

await userManager.AddToRoleAsync(
    admin,
    Roles.Admin
);

This makes the seeder idempotent—we can run it every time the application starts without continuously creating duplicate users or roles.

Note: In a real production application, don't hardcode an administrator password such as Admin@123 in source code. Store it in a secure configuration mechanism such as User Secrets for development and a secret manager in production.

Registration and Login

Now that Identity and JWT authentication are configured, let's implement the actual registration and login flow.

Registration

The Register method is responsible for creating a new user and issuing tokens after successful registration.

First, we check whether an account with the provided email already exists:

var existingUser = await userManager.FindByEmailAsync(command.Email);

if (existingUser != null)
{
    throw new Exception(
        "User with this email already exists"
    );
}

If an account already exists, we throw a Exception instead of creating another account.

We also perform a validation before creating the user:

if (command.Password != command.ConfirmPassword)
{
    throw new Exception(
        "password and confirm password doesn't match"
    );
}

The validation makes sure that the password and confirmation password match.

Once the validation succeeds, we create our ApplicationUser:

ApplicationUser user = new()
{
    Email = command.Email,
    SecurityStamp = Guid.NewGuid().ToString(),
    UserName = command.Email,
    Name= command.FullName,
    EmailConfirmed = true,
};

We then let ASP.NET Core Identity create the user:

var createUserResult = await userManager
    .CreateAsync(user, command.Password);

Identity takes care of processing the password and storing the user securely.

If user creation fails, we collect the Identity errors and throw a Exception:

if (createUserResult.Succeeded == false)
{
    var errors = createUserResult.Errors
        .Select(e => e.Description);

    throw new Exception(
        $"Failed to create user. Errors: {string.Join(", ", errors)}"
    );
}

Assigning the User Role

After creating the user, we assign the User role:

var addUserToRoleResult = await userManager
    .AddToRoleAsync(user, Roles.User);

This is important because the user's role will later be included as a claim in the JWT.

If the role assignment fails, we return an error:

if (addUserToRoleResult.Succeeded == false)
{
    var errors = addUserToRoleResult.Errors
        .Select(e => e.Description);

    throw new BadRequestException(
        $"Failed to assign user role. Errors: {string.Join(", ", errors)}"
    );
}

Creating Claims

Once the user has been created and assigned a role, we create the claims that will be included in the JWT:

List<Claim> authClaims =
[
    new Claim(
        ClaimTypes.NameIdentifier,
        user.Id.ToString()
    ),

    new Claim(
        ClaimTypes.Email,
        user.Email
    ),

    new Claim(
        ClaimTypes.Name,
        user.UserName
    ),

    new Claim(
        JwtRegisteredClaimNames.Jti,
        Guid.NewGuid().ToString()
    )
];

We then retrieve the roles assigned to the user:

var userRoles = await userManager.GetRolesAsync(user);

Each role is added as a ClaimTypes.Role claim:

foreach (var userRole in userRoles)
{
    authClaims.Add(
        new Claim(ClaimTypes.Role, userRole)
    );
}

This allows ASP.NET Core's authorization system to determine the user's role when the JWT is later presented to a protected endpoint.

Generating the Tokens

Now we can generate the access token and refresh token:

var accessToken =
    tokenService.GenerateAccessToken(authClaims);

string refreshToken =
    tokenService.GenerateRefreshToken();

The refresh token and its expiration time are then stored on the user:

user.RefreshToken = refreshToken;
user.RefreshTokenExpiryTime =
    DateTime.UtcNow.AddDays(7);

await userManager.UpdateAsync(user);


  public async Task<RegisterCommandResponse> Register(RegisterCommand command)
  {

      var existingUser = await userManager.FindByEmailAsync(command.Email);
      if (existingUser != null)
      {
          throw new Exception("User with this email already exists");
      }

      if(command.Password != command.ConfirmPassword)
      {
          throw new Exception("password and confirm password doesn't match");
      }





      ApplicationUser user = new()
      {
          Email = command.Email,
          SecurityStamp = Guid.NewGuid().ToString(),
          UserName = command.Email,
          Name= command.Name,
          EmailConfirmed = true,
      };





      var createUserResult = await userManager.CreateAsync(user, command.Password);


      if (createUserResult.Succeeded == false)
      {
          var errors = createUserResult.Errors.Select(e => e.Description);

          throw new BadRequestException ($"Failed to create user. Errors: {string.Join(", ", errors)}");
      }

      var addUserToRoleResult = await userManager.AddToRoleAsync(user: user, role: Roles.User);

      if (addUserToRoleResult.Succeeded == false)
      {
          var errors = addUserToRoleResult.Errors.Select(e => e.Description);
          throw new BadRequestException( $"Failed to assign user role. Errors: {string.Join(", ", errors)}");
      }




       List<Claim> authClaims = [
          new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
          new Claim(ClaimTypes.Email, user.Email),
          new Claim(ClaimTypes.Name, user.UserName),
          new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()), 
      ];

      var userRoles = await userManager.GetRolesAsync(user);

      foreach (var userRole in userRoles)
      {
          authClaims.Add(new Claim(ClaimTypes.Role, userRole));
      }

      var accessToken = tokenService.GenerateAccessToken(authClaims);

      string refreshToken = tokenService.GenerateRefreshToken();


      user.RefreshToken = refreshToken;
      user.RefreshTokenExpiryTime = DateTime.UtcNow.AddDays(7);

      await userManager.UpdateAsync(user);





      return new RegisterCommandResponse
      {
          accessToken = accessToken,
          refreshToken = refreshToken
      };
  }
    ```
{% endraw %}


# Login

The login process is very similar, except that instead of creating a new user, we first validate the existing user's credentials.

We find the user using the email address:
{% raw %}


```csharp
var user = await userManager
    .FindByEmailAsync(command.Email);

if (user == null)
{
    throw new UnAuthorizedException(
        "User with this Email is not registered with us."
    );
}

Next, we validate the password using Identity's UserManager:

bool isValidPassword =
    await userManager.CheckPasswordAsync(
        user,
        command.Password
    );

if (isValidPassword == false)
{
    throw new UnAuthorizedException(
        "invalid credentials"
    );
}

If the credentials are valid, we create the claims in the same way as we did during registration:

List<Claim> authClaims =
[
    new Claim(
        ClaimTypes.NameIdentifier,
        user.Id.ToString()
    ),

    new Claim(
        ClaimTypes.Email,
        user.Email
    ),

    new Claim(
        ClaimTypes.Name,
        user.UserName
    ),

    new Claim(
        JwtRegisteredClaimNames.Jti,
        Guid.NewGuid().ToString()
    )
];

Then we retrieve the user's roles and add them to the claims:

var userRoles =
    await userManager.GetRolesAsync(user);

foreach (var userRole in userRoles)
{
    authClaims.Add(
        new Claim(ClaimTypes.Role, userRole)
    );
}

Finally, we generate a new access token and refresh token:

var accessToken =
    tokenService.GenerateAccessToken(authClaims);

string refreshToken =
    tokenService.GenerateRefreshToken();

The refresh token is stored against the user and given a seven-day expiration:

user.RefreshToken = refreshToken;
user.RefreshTokenExpiryTime =
    DateTime.UtcNow.AddDays(7);

await userManager.UpdateAsync(user);

The refresh token will become especially important when the access token expires. Instead of forcing the user to log in again, we can use the refresh token to obtain a new pair of tokens.

public async Task<LoginCommandResponse> Login(LoginCommand command)
{

    var user = await userManager.FindByEmailAsync(command.Email);
    if (user == null)
    {
        throw new UnAuthorizedException("User with this Email is not registered with us.");
    }
    bool isValidPassword = await userManager.CheckPasswordAsync(user, command.Password);
    if (isValidPassword == false)
    {
         throw new UnAuthorizedException("invalid credentials");
    }

    List<Claim> authClaims = [
        new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
        new Claim(ClaimTypes.Email, user.Email),
        new Claim(ClaimTypes.Name, user.UserName),
        new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()), 
    ];

    var userRoles = await userManager.GetRolesAsync(user);

    foreach (var userRole in userRoles)
    {
        authClaims.Add(new Claim(ClaimTypes.Role, userRole));
    }

    var accessToken = tokenService.GenerateAccessToken(authClaims);

    string refreshToken = tokenService.GenerateRefreshToken();


    user.RefreshToken = refreshToken;
    user.RefreshTokenExpiryTime = DateTime.UtcNow.AddDays(7);

    await userManager.UpdateAsync(user);

    return new LoginCommandResponse
    {
        accessToken = accessToken,
        refreshToken = refreshToken
    };
}

Refresh Token

The access token we generate during login is short-lived. Once it expires, the client can no longer use it to access protected endpoints.

Instead of asking the user to log in again, we can use the refresh token to generate a new access token.

Let's implement this flow in the Refresh method of our AuthService.

Getting the User from the Expired Token

The first step is to extract the user's claims from the expired access token:

var principal =
    tokenService.GetPrincipalFromExpiredToken(
        command.accessToken
    );

Normally, an expired JWT would fail lifetime validation. However, our token service has a separate method that validates the token while allowing us to retrieve the claims from an expired access token.

From the principal, we can retrieve the username:

var username = principal.Identity.Name;

We can then use this username to find the corresponding user:

var user =
    await userManager.FindByNameAsync(username);

if (user == null)
{
    throw new UnAuthorizedException(
        "user is null."
    );
}

Validating the Refresh Token

Finding the user is not enough. We also need to make sure that the refresh token provided by the client is the same refresh token that we have stored for that user.

if (user.RefreshToken != command.refreshToken)
{
    throw new UnAuthorizedException(
        "refresh token doesn't match."
    );
}

We also check whether the refresh token has expired:

if (user.RefreshTokenExpiryTime <= DateTime.UtcNow)
{
    throw new UnAuthorizedException(
        "refresh token time expired."
    );
}

So, a refresh request is accepted only when:

The access token can be validated and its claims extracted.
The corresponding user exists.
The provided refresh token matches the stored refresh token.
The refresh token has not expired.

Generating New Tokens

Once all the validations pass, we generate a new access token using the claims from the existing token:

var newAccessToken =
    tokenService.GenerateAccessToken(
        principal.Claims
    );

We also generate a completely new refresh token:

var newRefreshToken =
    tokenService.GenerateRefreshToken();

We then replace the old refresh token with the new one:

user.RefreshToken = newRefreshToken;

user.RefreshTokenExpiryTime =
    DateTime.UtcNow.AddDays(7);

await userManager.UpdateAsync(user);

This means the old refresh token is no longer valid.

This approach is known as refresh token rotation. Every successful refresh generates a new refresh token instead of continuing to use the same one.

The client can now replace its old tokens with these newly generated tokens and continue making authenticated requests.

  public async Task<RefreshCommandResponse> Refresh(RefreshCommand command)
  {
      var principal = tokenService.GetPrincipalFromExpiredToken(command.accessToken);
      var username = principal.Identity.Name;

      var user = await userManager.FindByNameAsync(username);
      if (user == null)
      {
         throw new UnAuthorizedException("user is null.");
      }

      if (user == null || user.RefreshToken != command.refreshToken)
      {
          throw new UnAuthorizedException("refresh token doesn't match.");
      }

      if (user == null ||  user.RefreshTokenExpiryTime <= DateTime.UtcNow)
      {
          throw new UnAuthorizedException("refresh token time expired.");
      }

      var newAccessToken = tokenService.GenerateAccessToken(principal.Claims);
      var newRefreshToken = tokenService.GenerateRefreshToken();

      user.RefreshToken = newRefreshToken;
      user.RefreshTokenExpiryTime = DateTime.UtcNow.AddDays(7);

      await userManager.UpdateAsync(user);

      return new RefreshCommandResponse
      {
          accessToken = newAccessToken,
          refreshToken = newRefreshToken
      };
  }

Logout

Now that we have registration, login, and refresh token functionality, we also need to implement logout.

Logging out should invalidate the refresh token so that it can no longer be used to obtain new access tokens.

In our implementation, the logout operation is handled by the Logout method.

Getting the Current User

We first check whether we have an authenticated user:

if (currentUser.UserId == null)
{
    throw new UnAuthorizedException(
        "unauthorized access"
    );
}

Our ICurrentUser abstraction provides the ID of the currently authenticated user from the JWT claims.

Once we have the user ID, we retrieve the user through UserManager:

var user =
    await userManager.FindByIdAsync(
        currentUser.UserId
    );

if (user == null)
{
    throw new UnAuthorizedException(
        "unAuthorized access"
    );
}

Invalidating the Refresh Token

Once we have the user, we remove the stored refresh token:

user.RefreshToken = null;
user.RefreshTokenExpiryTime = null;

await userManager.UpdateAsync(user);

This is important because simply removing the token from the client is not enough.

If someone has obtained a valid refresh token before logout, they could potentially continue using it.

By removing the refresh token from the database, the server can no longer validate that token.

After logout, the previously stored refresh token can no longer be used to obtain a new access token.

 public async Task<LogoutCommandResponse> Logout(LogoutCommand command)
 {
     if (currentUser.UserId == null)
     {
         throw new UnAuthorizedException("unauthorized access");
     }

     var user = await userManager.FindByIdAsync(currentUser.UserId);

     if(user == null)
     {
         throw new UnAuthorizedException("unAuthorized access");
     }

     user.RefreshToken = null;
     user.RefreshTokenExpiryTime = null;

     await userManager.UpdateAsync(user);

     return new LogoutCommandResponse { };

 }```

Sending Email Using Gmail SMTP

harshvardhan — Tue, 18 Aug 2026 02:22:51 +0000

*1. Create the Email Service Interface
*

public interface IEmailService
{
Task SendEmailAsync(
string recipientEmail,
string subject,
string body);
}

2. Implement the Email Service

using System.Net;
using System.Net.Mail;

public class EmailService : IEmailService
{
private readonly IConfiguration _configuration;

public EmailService(IConfiguration configuration)
{
    _configuration = configuration;
}

public async Task SendEmailAsync(
    string recipientEmail,
    string subject,
    string body)
{
    var senderEmail =
        _configuration["EmailSettings:Email"];

    var senderPassword =
        _configuration["EmailSettings:Password"];

    using var mailMessage = new MailMessage
    {
        From = new MailAddress(senderEmail!),
        Subject = subject,
        Body = body,
        IsBodyHtml = true
    };

    mailMessage.To.Add(recipientEmail);

    using var smtpClient =
        new SmtpClient("smtp.gmail.com", 587)
        {
            EnableSsl = true,
            Credentials = new NetworkCredential(
                senderEmail,
                senderPassword)
        };

    await smtpClient.SendMailAsync(mailMessage);
}

}

3. Add Email Configuration

{
"EmailSettings": {
"Email": "your-email@gmail.com",
"Password": "your-app-password"
}

Handling JWT Authentication & Refresh Tokens in Angular Using an HTTP Interceptor

harshvardhan — Mon, 10 Aug 2026 16:59:52 +0000

While working on authentication in Angular, one thing I found particularly useful was using an HTTP interceptor to handle authentication automatically.

Instead of manually adding the access token to every API request, the interceptor can:

Attach the JWT access token to outgoing requests
Detect 401 Unauthorized responses
Use the refresh token to obtain a new access token
Retry the failed request automatically
Logout the user if the refresh token is expired/invalid

Here's the approach I used.

Adding the Access Token to Requests

First, I retrieve the authentication data from localStorage:

const getAuth = () => {
  const stored = localStorage.getItem('auth');
  return stored ? JSON.parse(stored) : null;
};

const auth = getAuth();
let authReq = req;

If an access token exists, I clone the request and add the Authorization header:

if (auth?.accessToken) {
  authReq = req.clone({
    setHeaders: {
      Authorization: `Bearer ${auth.accessToken}`,
    },
  });
}

Now every API request automatically contains:

Authorization: Bearer

This means I don't need to manually add the token in every service method.

Handling 401 Unauthorized

The access token is usually short-lived for security reasons.

Eventually, it can expire and the API may respond with:

401 Unauthorized

Instead of immediately logging the user out, I check whether a refresh token is available:

if (error.status === 401 && auth?.refreshToken)

Then I call my refresh-token endpoint:

return authService.refreshToken().pipe

The backend validates the refresh token and returns a new access token.

Retrying the Failed Request

Once I receive the new tokens, I store them:

switchMap((newTokens: any) => {
authService.setUser(newTokens);

Then I create a new version of the original request using the new access token:

const retryReq = req.clone({
setHeaders: {
Authorization: Bearer ${newTokens.accessToken},
},
});

return next(retryReq);

So the flow becomes:

API Request
↓
Access Token
↓
Server
↓
401 Unauthorized
↓
Refresh Token
↓
New Access Token
↓
Retry Original Request

The user doesn't have to manually log in again.

What Happens If Refresh Fails?

The refresh token itself can also expire or become invalid.

In that situation, the refresh request will fail.

I handle that using another catchError:

catchError((refreshError) => {
  authService.clearUser();
  router.navigate(['/login']);

  return throwError(() => refreshError);
})

The authentication data is removed and the user is redirected to the login page.

Important: Don't Refresh the Refresh Request

There is one edge case we need to handle.

Suppose /Auth/Refresh itself returns 401.

If our interceptor tries to refresh that request again, we could end up with an infinite loop.

So I check:

const isRefreshRequest = req.url.includes('/Auth/Refresh');

If the failed request is already the refresh request, I immediately logout:

if (isRefreshRequest) {
  authService.clearUser();
  router.navigate(['/login']);

  return throwError(() => error);
}

This prevents the interceptor from repeatedly trying to refresh an already-invalid refresh token.

Putting everything together:

import { HttpErrorResponse, HttpInterceptorFn } from '@angular/common/http';
import { inject } from '@angular/core';
import { AuthService } from '../service/auth-service';
import { Router } from '@angular/router';
import { catchError, switchMap, throwError } from 'rxjs';

export const authInterceptor: HttpInterceptorFn = (req, next) => {
  const authService = inject(AuthService);
  const router = inject(Router);

  const getAuth = () => {
    const stored = localStorage.getItem('auth');
    return stored ? JSON.parse(stored) : null;
  };

  const auth = getAuth();
  let authReq = req;

  if (auth?.accessToken) {
    authReq = req.clone({
      setHeaders: {
        Authorization: `Bearer ${auth.accessToken}`,
      },
    });
  }

  return next(authReq).pipe(
    catchError((error: HttpErrorResponse) => {
      const isRefreshRequest = req.url.includes('/Auth/Refresh');

      if (isRefreshRequest) {
        authService.clearUser();
        router.navigate(['/login']);
        return throwError(() => error);
      }

      if (error.status === 401 && auth?.refreshToken) {
        return authService.refreshToken().pipe(
          switchMap((newTokens: any) => {
            authService.setUser(newTokens);

            const retryReq = req.clone({
              setHeaders: {
                Authorization: `Bearer ${newTokens.accessToken}`,
              },
            });
            return next(retryReq);
          }),
          catchError((refreshError) => {
            authService.clearUser();
            router.navigate(['/login']);
            return throwError(() => refreshError);
          }),
        );
      }
      return throwError(() => error);
    }),
  );
};

The main advantage is that authentication logic stays in one place.

Without an interceptor, every API service might need to deal with:

Get token
↓
Add Authorization header
↓
Make request
↓
Check 401
↓
Refresh token
↓
Retry request

With an interceptor, the individual services can stay focused on their actual responsibilities and The interceptor takes care of authentication automatically.