DEV Community: elshwilahmed

Securing a .NET API with JWT Authentication Using Clean Architecture

elshwilahmed — Fri, 16 Oct 2026 20:19:11 +0000

When building a RESTful API, securing your endpoints is just as important as the business logic itself. While implementing JWT (JSON Web Tokens) in a standard .NET application is common, doing it correctly within a Clean Architecture structure requires careful separation of concerns. You don't want your Core Domain knowing about HTTP requests, libraries, or token generation algorithms.

In this article, I'll show you how I implemented a decoupled, secure JWT authentication system in my latest .NET API, ensuring that the infrastructure logic remains completely isolated from the business rules.

The Contract (Interface) To keep my API Controllers clean and easily testable, I rely on the Service Pattern. The controller shouldn't care about the specific packages or algorithms used to generate a token.

To achieve this, I defined a simple interface inside my Services folder.

using SarahaAPI.Models;

namespace SarahaAPI.Services
{
    public interface IJWTService
    {
        public string GenerateToken(User user);
    }
}

The Implementation (Service Layer) Next, I implement this interface in the JWTService class. This class handles the actual token generation using the System.IdentityModel.Tokens.Jwt library. By isolating this logic in the Service layer, the API controller only interacts with the interface, keeping it decoupled from the token generation process.

using System.IdentityModel.Tokens.Jwt;
using System.Security.Claims;
using System.Security.Cryptography;
using System.Text;
using Microsoft.IdentityModel.Tokens;
using SarahaAPI.Models;

namespace SarahaAPI.Services
{
    public class JWTService : IJWTService
    {
        readonly IConfiguration _config;

        public JWTService(IConfiguration configuration)
        {
            _config = configuration;
        }

        public string GenerateToken(User user)
        {
            var claims = new[]
           {
                new Claim(ClaimTypes.NameIdentifier, user.Id.ToString()),
                new Claim(ClaimTypes.Name, user.UserName),
                new Claim(ClaimTypes.Email, user.Email)
            };

            var creds = new SigningCredentials(
                 new SymmetricSecurityKey(Encoding.UTF8.GetBytes(_config["Jwt:SecretKey"])), SecurityAlgorithms.HmacSha256);

            var token = new JwtSecurityToken
            (
               issuer: _config["JWT:Issuer"],
               audience: _config["JWT:Audience"],
               claims: claims,
                 signingCredentials: creds,
                 expires: DateTime.UtcNow.AddDays(1)
            );

            return new JwtSecurityTokenHandler().WriteToken(token);
        }
    }
}

Configuration and Dependency Injection (Program.cs) Finally, I need to configure ASP.NET Core to validate JWTs and register my services in the Dependency Injection container. I also configured Swagger to accept Bearer tokens so the API can be easily tested from the browser.

using System.Text;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.EntityFrameworkCore;
using Microsoft.IdentityModel.Tokens;
using Microsoft.OpenApi.Models;
using Saraha.core.Interfaces;
using Saraha.infrastructure.Repositories;
using SarahaAPI.Data;
using SarahaAPI.filters;
using SarahaAPI.Middlewares;
using SarahaAPI.Services;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddControllers(
    Options => Options.Filters.Add<LogInputArgumentsFilter>()
    );
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen(c =>
{
    c.AddSecurityDefinition("Bearer", new OpenApiSecurityScheme
    {
        Description = "Enter 'Bearer' [space] and then your token in the text input below.\r\n\r\nExample: 'Bearer eyJhbGci...'",
        Name = "Authorization",
        In = ParameterLocation.Header,
        Type = SecuritySchemeType.ApiKey,
        Scheme = "Bearer"
    });

    c.AddSecurityRequirement(new OpenApiSecurityRequirement()
    {
        {
            new OpenApiSecurityScheme
            {
                Reference = new OpenApiReference
                {
                    Type = ReferenceType.SecurityScheme,
                    Id = "Bearer"
                },
                Scheme = "oauth2",
                Name = "Bearer",
                In = ParameterLocation.Header,
            },
            new List<string>()
        }
    });
});

builder.Services.AddDbContext<SarahaDbContext>(
    options => options.UseSqlServer(builder.Configuration.GetConnectionString("DBAdress"))
    );

builder.Services.AddAuthentication(
    JwtBearerDefaults.AuthenticationScheme
    ).AddJwtBearer(
    options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = builder.Configuration["Jwt:Issuer"],
            ValidAudience = builder.Configuration["Jwt:Audience"],
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:SecretKey"]!))
        };
    });

builder.Services.AddScoped<IUnitOfWork, UnitOfWork>();

builder.Services.AddScoped<IMessageService, MessageService>();
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddScoped<IJWTService, JWTService>();
builder.Services.AddScoped<IAccountService, AccountService>();

var app = builder.Build();
app.UseMiddleware<ExceptionMiddleware>();
app.UseMiddleware<RequestTimingMiddleware>();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
    app.UseSwagger();
    app.UseSwaggerUI();
}

app.UseHttpsRedirection();

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

app.MapControllers();

app.Run();

Conclusion
By separating the token generation into its own service (IJWTService) using the Service Pattern, I kept my controllers clean and highly testable. The core business logic remains completely isolated from the authentication implementation details.

You can check out the complete Saraha API Clone source code (including BCrypt password hashing and custom Middlewares) on my GitHub repository here:
https://github.com/elshwilahmed/Saraha-API

Implementing the Factory Pattern for Multiple Payment Gateways in .NET Core

elshwilahmed — Fri, 16 Oct 2026 19:58:41 +0000

Building an e-commerce API is straightforward until you need to support multiple payment gateways like Stripe and Paymob. The naive approach is to use endless if-else or switch statements inside your controllers to determine which payment service to call. This violates the Open/Closed Principle and makes the codebase tightly coupled and very hard to maintain.

In this article, I will show you how I used the Factory Design Pattern in C# to resolve and manage multiple payment gateways, keeping my .NET Core application scalable and clean.

The Contract (Interface): IPaymentGateway First, I need a unified contract. Every payment gateway I integrate must implement this interface. This ensures my core application doesn't care about the specific implementation details of Paymob or Stripe.

public interface IPaymentGateway
{
    string GatewayName { get; }
    string Currency { get; }
    Task<APIResponse<PaymentResultDTO>> CreatePaymentIntentionAsync(UnifiedPaymentRequestDTO request);
    Task<APIResponse<string>> ProcessWebhookAsync(HttpRequest request);
}

The Implementations Next, I implement this interface for my specific providers. Notice how each class defines its own unique GatewayName.

Paymob Implementation:

public class PaymobGateway : IPaymentGateway
{
    public string GatewayName => "paymob";
    public string Currency => "EGP";

    // Dependencies like HttpClient, DbContext, and Settings injected here

    public async Task<APIResponse<PaymentResultDTO>> CreatePaymentIntentionAsync(UnifiedPaymentRequestDTO request)
    {
        // Paymob specific logic to generate payment intent and URL
        // ...
       return APIResponse<PaymentResultDTO>.Success(resultDto, "Payment intent created successfully"); 
    }

    public async Task<APIResponse<string>> ProcessWebhookAsync(HttpRequest request)
    {
        // Paymob specific HMAC verification and webhook processing
        // ...
        return APIResponse<string>.Success($"Order {order.Id} Paid Successfully!");
    }
}

Stripe Implementation:

public class StripeGateway : IPaymentGateway
{
    public string GatewayName => "stripe";
    public string Currency => "USD";

    public async Task<APIResponse<PaymentResultDTO>> CreatePaymentIntentionAsync(UnifiedPaymentRequestDTO request)
    {
        // Stripe specific logic to generate payment intent
        // ...
        return APIResponse<PaymentResultDTO>.Success(new PaymentResultDTO
{
    GatewayName = "Stripe",
    PaymentUrl = session.Url
}, "Stripe Session Created");
    }

    public Task<APIResponse<string>> ProcessWebhookAsync(HttpRequest request)
    {
         // Stripe specific webhook processing
         // ...
         return APIResponse<string>.Success("Webhook processed successfully");
    }
}

The Factory: Resolving Dependencies Dynamically This is where the magic happens. I create a Factory class that takes an IEnumerable. ASP.NET Core's Dependency Injection will inject all registered gateways into this list.

The Factory uses LINQ to match the requested gateway name with the GatewayName property of the injected services, ignoring case sensitivity for safety.

public interface IPaymentGatewayFactory
{
    IPaymentGateway GetGateway(string gatewayName);
}

public class PaymentGatewayFactory : IPaymentGatewayFactory
{
    private readonly IEnumerable<IPaymentGateway> _gateways;
    private readonly ILogger<PaymentGatewayFactory> _logger;

    public PaymentGatewayFactory(IEnumerable<IPaymentGateway> gateways, ILogger<PaymentGatewayFactory> logger)
    {
        _gateways = gateways;
        _logger = logger;
    }

    public IPaymentGateway GetGateway(string gatewayName)
    {
        var gateway = _gateways.FirstOrDefault(g => 
            g.GatewayName.Equals(gatewayName, StringComparison.OrdinalIgnoreCase));

        if (gateway == null)
        {
            _logger.LogError($"Gateway Name '{gatewayName}' Not Found");
            throw new ArgumentException($"Payment gateway '{gatewayName}' is not supported.");
        }

        return gateway;
    }
}

Wiring it up in Dependency Injection (Program.cs) To make this work, I register multiple implementations for the same interface IPaymentGateway, and then register my Factory.

// Register multiple gateways
builder.Services.AddScoped<IPaymentGateway, PaymobGateway>();
builder.Services.AddScoped<IPaymentGateway, StripeGateway>();

// Register the factory
builder.Services.AddScoped<IPaymentGatewayFactory, PaymentGatewayFactory>();

Using it in the Controller Now, our Controller is completely decoupled. It doesn't know anything about Paymob or Stripe. It just asks the factory for the requested gateway and executes the payment!

[ApiController]
[Route("api/[controller]")]
public class CheckoutController : ControllerBase
{
    private readonly IPaymentGatewayFactory _gatewayFactory;

    public CheckoutController(IPaymentGatewayFactory gatewayFactory)
    {
        _gatewayFactory = gatewayFactory;
    }

    [HttpPost("pay")]
    public async Task<IActionResult> ProcessPayment([FromQuery] string provider, [FromBody] UnifiedPaymentRequestDTO request)
    {
        // 1. Get the correct gateway based on the user's choice
        var gateway = _gatewayFactory.GetGateway(provider);

        // 2. Process the payment
        var result = await gateway.CreatePaymentIntentionAsync(request);

        return Ok(result);
    }
}

Conclusion
By taking advanatage of the Factory Pattern and ASP.NET Core's built-in Dependency Injection, I built a scalable payment module. If i want to add PayPalGateway tomorrow or another gateway, I just create the class and register it in Program.cs without modifying the Controller or the Factory. This adheres to the Open/Closed Principle.

Check out the complete source code, including the real-time Webhook handling and database transactions, on my GitHub:
https://github.com/elshwilahmed/PaymentGateways-API

Building a Decoupled Order Notification System in C# Using the Observer Pattern

elshwilahmed — Fri, 16 Oct 2026 19:20:12 +0000

The Solution: The Observer Pattern
To decouple our system, we can use the Observer Pattern. In C#, this is implemented using delegate and event.

The OrderService will act as the Publisher. It doesn't know who will receive the notification; it just announces that "An order has been placed".
The notification services EmailService and SMSService will act as Subscribers.

The Publisher (OrderService) Here, we define an Action event. Notice how we use a Predicate to evaluate business rules (checking if the order price meets a condition) before firing the event using Invoke function.

public class OrderService
{
    public event Action<OrderService> OrderPlaced;

    public string Name { get; set; }
    public double Price { get; set; }

    public OrderService(string name, double price)
    {
        Name = name;
        Price = price;
    }

    public void ConfirmOrder(Predicate<double> condition)
    {
        Console.WriteLine($"Order '{Name}' has been successfully placed!");

        // Evaluate condition before firing the event
        if (condition(Price))
        {
            OrderPlaced?.Invoke(this);
        }
        Console.WriteLine("-------------------------------------------------");
    }
}

The Subscribers (Notification Services) These classes are independent of the OrderService. They just need a method whose signature matches the Action delegate.

public class SMSService
{
    public void Notification(OrderService order) 
    {
        Console.WriteLine($"[SMS] Sending text message: Your order '{order.Name}' is confirmed!");
    }
}

public class EmailService
{
    public void Notification(OrderService order)
    {
        Console.WriteLine($"[Email] Sending email: Thank you for your order '{order.Name}' is confirmed!");
    }
}

Wiring It All Together In my code, I subscribe the services to the OrderPlaced event using the += operator. If I want to remove a service later, we simply use -=.

class Program
{
    static void Main(string[] args)
    {
        OrderService order = new("Exercise Straps", 228);

        SMSService sendSMS = new();
        EmailService sendEmail = new();

        // Subscribe to the event
        order.OrderPlaced += sendEmail.Notification;
        order.OrderPlaced += sendSMS.Notification;

        // Confirm order with a condition (price > 200)
        order.ConfirmOrder(x => x > 200);
    }
}

Conclusion: Why This Matters

By using the Observer Pattern with C# delegates and events, I transformed a tightly coupled method into a scalable and flexible system.

If i ever need to add a WhatsAppNotificationService, I simply create the class and subscribe it to the OrderPlaced event without touching the main OrderService at all. This is the importance of the Open/Closed Principle!

You can check out the complete, working code for this project on my GitHub repository here:
https://github.com/elshwilahmed/CAT-Task6-Order-Notification-System/tree/main

How do you handle event-driven architectures in your .NET projects? Let me know in the comments!