Forem: Татьяна Кузнецова

Authorization methods in .NET microservices

Татьяна Кузнецова — Fri, 20 Feb 2026 10:49:41 +0000

Today I want to dive into one of the most critical stages of microservices development: authorization. This stage can bring significant complexity. Each service is now a separate HTTP server with its own endpoints, and the client (bot, frontend, mobile app) must have simultaneous access to all of them.

Theory: Authentication vs Authorization in Microservices

In microservices architecture, it's crucial to distinguish between:

Authentication — who is this?
Authorization — what is this subject allowed to do?

Authentication is typically handled by a dedicated Identity Provider (IdP) or Auth service, while microservices accept already-validated tokens and decide what the client can access.

Main Authorization Approaches in Microservices

Session-based authorization (cookies + server-side session store)
Token-based: -> JWT (JSON Web Token) -> Opaque tokens
OAuth 2.0 / OpenID Connect (OIDC) on top of tokens (usually JWT)
API Keys
mTLS (mutual TLS) — mutual TLS authentication between services
Combinations (e.g., OIDC+JWT for users + mTLS between services)

🔐 JWT — compact signed token with claims (sub, roles, scopes, etc.) that can be validated locally without accessing shared state.

🌐 OAuth2/OIDC — protocols defining:

How clients obtain tokens
How SSO is implemented
Token format (JWT or opaque) is a separate layer

📈 Approach Features & 2026 Trends

Key trend: Moving authentication (and part of authorization) to a centralized IdP/Auth-hub, while microservices become "resource servers" that trust validated tokens.

Centralized IdP/Auth-hub + Resource Servers Pattern

Centralized IdP:

Stores user accounts, login methods, MFA, social login, etc.
Implements OAuth2/OIDC protocols and issues tokens (access, refresh, ID token)
Serves as the single source of truth for authentication and basic roles/groups

Resource Servers (microservices):

Host protected resources
Accept only requests with valid tokens (OAuth2 terminology)

Simultaneous zero-trust hardening: Even inside the cluster, services explicitly authenticate (mTLS, certificates, SPIFFE).

Quick Overview of Approaches

Approach	Key Characteristics
Sessions	Simpler for classic web apps/monoliths. Requires shared session store or sticky sessions in microservices (scaling complexity).
JWT	Stateless approach, perfect for microservices + API gateway. De facto standard for OAuth2/OIDC access tokens in 2026.
OAuth2/OIDC	Industry standard for external clients, mobile, SPA, B2B. Easy SSO, MFA, social login via IdP.
API Keys	Simple keys for machine-to-machine access/integrations. Often combined with IP limits, rate limiting, gateway policies in 2026.
mTLS	Standard service-to-service auth in service mesh (Istio, Linkerd, Consul). Guarantees "this pod is exactly that service" but carries no user rights.

Modern production standard: API Gateway/Ingress + OAuth2/OIDC + JWT + mTLS inside mesh.

1️⃣ Sessions (Cookies + Server-Side Sessions)

How It Works

- User logs in on server (password, MFA)
- Server generates unique session ID and stores full session in store (Redis, SQL, Memcached)
- Session ID written to cookie (typically HttpOnly, Secure, SameSite=Strict/Lax)
- Subsequent requests → server reads session ID from cookie → fetches session data from store
- If session found and not expired → user authenticated

Microservices variants:

Sticky sessions: Load balancer binds user to one pod/service (by cookie)
Shared session store: All microservices read from central store (Redis cluster)

✅ Advantages

Implementation simplicity: Built into ASP.NET Core, Spring, Rails etc. No protocols to learn
Centralized control: Easy to revoke/end session in store (e.g., suspected compromise)
Security: Cookie contains no sensitive data (just ID), forgery-resistant (proper HttpOnly, Secure)
Perfect for SSR/traditional web: Browser auto-sends cookies

❌ Disadvantages & Microservices Issues

Scaling: Requires resilient session store → central point of failure
Redis outage = mass logout of ALL users
Sticky sessions limit flexibility: Can't freely scale/restart pods, hard multi-region migration
Performance: Every request = store read (network roundtrip), accumulates across services
Poor API/mobile/SPA fit: Cookie issues (CORS, cross-domain, native apps)
CSRF/XSS: Requires extra measures (CSRF tokens, SameSite)

When to Use

✅ Classic SSR web apps without complex API architecture
✅ Internal admin panels where simplicity > scale
✅ Monolith-to-microservices transition period
❌ Pure REST APIs, SPAs, mobile clients

2026 status: Rarely used in pure microservices, survives in legacy/BFF for web UI.

2️⃣ JWT (JSON Web Token)

How It Works

JWT consists of three parts:

Header – signing algorithm
Payload – claims (sub, roles, scopes, etc.)
Signature – signed with a private key

Flow:

After login, the Auth service generates a JWT with the required claims and signs it with a private key.
The client attaches the JWT to every request in the header: Authorization: Bearer <jwt_token>
Each microservice validates locally:
- Signature (using IdP public key from JWKS endpoint)
- exp (expiration), iss (issuer), aud (audience), nbf (not before)
- Claims (roles, scopes, etc.)
If everything is valid, the service uses claims for authorization.

Signing options:

Symmetric (shared secret) — simpler, but worse for distributed systems
Asymmetric (RS256/ECDSA) — standard; public key exposed via JWKS

✅ Advantages

Stateless: No central session store, each service verifies tokens independently — perfect for microservices
Scalable: To add a new service, you just give it the IdP public key
Flexible claims: You can embed roles, tenant, permissions, feature flags — the service sees everything it needs immediately
Standard: Native support in all major frameworks (ASP.NET Core JwtBearer, Spring Security, etc.)
Cross-platform: Works equally well for browsers, mobile apps, CLI tools, partners

❌ Disadvantages

Revocation is hard: Until the token expires (usually 15–60 minutes), it remains valid
- Workarounds: short TTL + refresh tokens, blacklists, introspection endpoints (but this hurts statelessness)
Token size: Can be large with many claims, increasing HTTP header size
Claims leakage: If a token is captured, the attacker can read roles/rights (though cannot forge signature)
Crypto pitfalls: Incorrect validation (not checking iss/aud/exp) is a common vulnerability

When to Use

Primary format for access tokens in microservice architectures
Always in combination with OAuth2/OIDC
Standalone — for simple internal APIs

2026 status: De facto standard access token format in OAuth2/OIDC, typically with short-lived access tokens + refresh tokens.

3️⃣ OAuth2 / OIDC

How It Works

OAuth2 is an authorization protocol (how a client obtains a token with specific access rights).
OIDC (OpenID Connect) is an identity layer on top of OAuth2 (who is the user).

Roles:

Resource Owner — the user
Client — SPA, mobile app, BFF
Authorization Server — IdP (Auth server)
Resource Server — microservice (API)

Main Flows Used with Microservices

Authorization Code Flow + PKCE (for SPA/mobile):
- Client redirects the user to the IdP
- After login, IdP returns an authorization code
- Client exchanges the code for access and refresh tokens
Client Credentials Flow (service-to-service):
- Service uses client_id/client_secret to obtain a token on its own behalf
Implicit Flow (legacy, for old SPA apps — considered obsolete)
Device Code Flow (for TV/CLI and limited-input devices)

Token Types

Access Token — carries access rights (what the client can do)
Refresh Token — used to obtain new access tokens
ID Token (OIDC) — contains user identity information (who the user is)

✅ Advantages

Standardized: Works with any modern IdP (Keycloak, Auth0, Azure AD, Google, etc.)
SSO & federation: One login for all services, easy integration with external identity providers
Supports many client types: SPA, native apps, backend services, partners
Scopes & delegated access: Clients receive only the permissions they actually need (read:orders, write:payments, etc.)
Security features: PKCE against code injection, short-lived tokens, audit trails

❌ Disadvantages

Complexity: Many moving parts (redirect_uri, scopes, client_id, PKCE), easy to misconfigure
IdP dependency: IdP must be highly available and secure
Frontend complexity: SPA/mobile must correctly handle redirects, token storage, and silent refresh

When to Use

Any public REST APIs with external clients
Microservice systems that require SSO
B2B integrations and partner access

2026 status: The mandatory standard for enterprise and public-facing APIs.

4️⃣ API Keys

How It Works

A unique key is generated (typically a 32–64 character string, sometimes with a prefix).
The client (service, script, partner) sends the key in a header, for example:
- X-API-Key: abc123...
- or Authorization: ApiKey abc123...
The gateway/microservice validates the key against a database or cache (e.g., Redis).
The key is usually associated with:
- IP restrictions
- Rate limits
- Scopes
- Expiration time

✅ Advantages

Maximum simplicity: No complex protocols, redirects, or crypto handshakes
Fast to implement: Great for internal tools, CI/CD pipelines, partner systems
Flexible policies: Rate limiting, IP whitelists, daily/monthly quotas
Easy revocation: Just remove or disable the key in the database

❌ Disadvantages

No user identity: The key is tied to an application/service, not to an individual user
Coarse-grained access: Often “all or nothing” or very rough scopes
Key management overhead: Secure issuing, rotation, and audit are required
No inherent encryption: Keys can appear in logs/traffic — TLS is mandatory

When to Use

Internal services and scripts
Partner integrations without complex per-user permissions
Prototypes and proof-of-concept APIs

2026 status: Commonly used in combination with API gateways (rate limiting + IP checks), but not the primary method for user-facing authorization.

5️⃣ mTLS (Mutual TLS)

How It Works

With regular TLS, only the server presents a certificate to the client.

With mTLS, the verification is mutual:

The client service presents a client certificate (with SAN/pod name).
The server service verifies the client certificate (trusted CA, not expired, correct subject).
The server also presents its own certificate.
The connection is encrypted, and both sides know exactly who is on the other end.

mTLS in a Service Mesh (e.g., Istio)

A sidecar proxy (Envoy) automatically handles certificates (via Citadel/SPIRE).
Policies in AuthorizationPolicy / PeerAuthentication define rules like: > "OrderService is allowed to call PaymentService, but not the other way around."

✅ Advantages

Zero trust: You do not trust the network; every piece of traffic is authenticated
Automatic encryption inside the cluster
Observability: Easy to audit which service talked to which
Policy enforcement: Mesh-level RBAC based on certificates/identities

❌ Disadvantages

PKI complexity: Certificate rotation, CA management, revocation
Config sensitivity: One bad policy can break all traffic
Overhead: TLS handshakes on connections (though modern hardware handles this well)
Not about users: mTLS identifies services, not users — user permissions still need JWT/OAuth2/etc.

When to Use

Service-to-service communication inside a cluster
Zero-trust, enterprise environments, regulated industries
Always together with a service mesh

2026 status: The standard for production microservices running in a mesh, often as part of the “golden combo”:

API Gateway + OAuth2/JWT + mTLS.

🔄 Authorization Flows: Client → Gateway → Microservices

1️⃣ Client → IdP → API Gateway → Microservices (OAuth2/OIDC + JWT)

A typical modern setup: browser/SPA/mobile client → API Gateway/BFF → dozens of microservices.

🔐 Authentication at IdP (SSO)

The client opens the frontend, which redirects the user to the IdP using Authorization Code Flow (OIDC).
The user logs in (password, MFA, etc.).
The IdP creates a session and returns an authorization code to the client.
The client exchanges this code for an access token (often JWT) and a refresh token.

📥 Client → API Gateway

The client sends requests to the API Gateway with: Authorization: Bearer <access_token>
The gateway validates:
- JWT signature
- exp, iss, aud
- scopes / roles using the IdP’s JWKS endpoint.

📡 Gateway → Microservices

The gateway can either:

Proxy the original JWT downstream as-is, or
Issue a lightweight internal token for services (token exchange to an internal JWT).

Each microservice then either:

Validates the token itself; or
Trusts the gateway’s validation and uses the provided claims for authorization.

🧩 Authorization Inside Microservices

Basic (RBAC): Check roles/scopes from the token (admin, user, order.read, order.write, etc.).
Advanced (ABAC / policy-based):
- Fetch additional data from other services (fetch/replicate patterns).
- Delegate the decision to a centralized Authorization service.

2️⃣ Service-to-Service (S2S) Authorization

Pattern 1: Propagation (User Token Forwarding)

Service A receives a request with the user’s JWT.
When calling Service B, A forwards the same JWT.
Service B validates the token and checks the user’s permissions.

Use when you need end-to-end user identity across services.

Pattern 2: Service Account / Client Credentials

Each service gets its own client_id / client_secret / certificate.
A service uses Client Credentials Flow to obtain a machine-to-machine token.
It then calls other services on its own behalf, not the user’s.

Use when:

There is no end-user (batch jobs, schedulers), or
You need service-level permissions (e.g. “BillingService can call PaymentService”).

Pattern 3: mTLS in the Mesh

Inside the mesh, each pod/SAN is identified by a certificate.
Mesh policies (AuthorizationPolicy, etc.) define which service can call which.

User identity can:

Be propagated in JWT alongside mTLS, or
Be omitted completely for batch/technical processes where no end-user is involved.

⚙️ Resilience: How Painful Are Failures?

Let’s look at failure points for each approach. Key chain links:

IdP/Auth service
API Gateway
Session store / PKI / mesh control plane
Individual microservice

1️⃣ OAuth2/OIDC + JWT

IdP/Auth service down:

New logins and refresh token flows stop working
Existing access tokens continue to be accepted until they expire
Pain is delayed — the system degrades as tokens expire

API Gateway down:

External clients almost always lose access completely
Pain is acute, so the gateway must be scaled and protected aggressively

Single microservice down:

Only that service’s functionality breaks
The authorization mechanism as a whole still works

2️⃣ JWT Without a Central IdP

If each service validates JWT locally using cached keys:
- Auth service outage only affects new logins / key rotation
If services call Auth service on every validation (fetch strategy):
- Auth service outage makes all requests unauthenticated/unauthorized

2026 recommendation: avoid hard runtime dependency on the Auth service; always validate JWT locally.

3️⃣ Sessions

Session store (Redis, SQL) down:

All sessions become unavailable → users are massively logged out
Pain is usually maximal, since sessions are central shared state

Auth service that creates sessions down:

New logins are impossible
Existing sessions keep working as long as the session store is alive

4️⃣ API Keys

Key management service down:

You can’t issue/revoke keys
Existing keys continue to work

Gateway down:

Same as other schemes: very painful, as it’s usually the single entry point

5️⃣ mTLS

Control plane / PKI / mesh down:

Existing connections may work for a while
New certificates aren’t issued, old ones aren’t rotated
As certificates expire, more and more S2S calls start failing with TLS errors

Mesh policy misconfig / incompatible mTLS config:

Can instantly break a large portion of internal traffic ### 6️⃣ Resilience Summary Table

Approach	Central Component Failure (IdP/Auth/Session/PKI)	Pain Level
OAuth2 + JWT	No new logins/refresh, existing tokens work until `exp`	Delayed, manageable
JWT (local validation)	No new tokens issued, existing tokens keep working	Delayed
JWT (fetch to Auth)	Auth service unavailable → all validations fail	Acute, often critical
Sessions	Session store down → mass logout	Very painful
API Keys	Cannot manage keys, but existing keys still work	Usually moderate
mTLS	PKI/mesh down → gradual degradation of S2S traffic as certs expire	Growing, depends on DevOps quality

🧩 Authentication & Authorization Patterns in Microservices

Patterns are proven architectural solutions to recurring authorization problems. They help deal with distributed data, scale, and complexity.

As of 2026, the focus is on combining:

OAuth2/JWT for users
mTLS for service-to-service traffic
Delegated authorization for complex permissions

1️⃣ API Gateway / BFF as the Authentication Entry Point

Description:

An API Gateway (or Backend for Frontend, BFF) is the single entry point where:

Authentication happens
Coarse-grained authorization is enforced (basic checks: roles, scopes)

The token is then forwarded to microservices.

How it works:

Client → Gateway (with credentials or an existing token)
The gateway:
- Validates the token
- Checks roles/scopes
- Enriches the request with user context (headers/claims)
Gateway → Microservices (with token or extracted claims)
Microservices perform fine-grained authorization using their own data

Pros:

Single, well-defined entry point for external clients
Per-tenant isolation, rate limiting, traffic management
Minimizes duplicated auth logic across services

Cons:

Gateway becomes a single point of failure → must be highly available
Potential tight coupling if services depend heavily on the gateway’s claim format

Examples:

Ocelot / YARP (for ASP.NET)
Kong, KrakenD, NGINX, Traefik

2️⃣ Token Propagation

Description:

The user’s token (JWT) is passed from the client through the gateway to every microservice in the call chain. Each service validates the token and enforces its own access rules.

Variants:

End-user propagation:

The original user JWT is propagated end-to-end through all services.
Service token exchange:

The gateway exchanges the user JWT for a service token, which is then used internally.

Pros:

End-to-end user identity available in every microservice
Each service can independently enforce its own authorization rules (RBAC/ABAC)

Cons:

Token is validated in every service (CPU overhead)
Large tokens (many claims) increase request size across the entire call chain

When to use:

User-centric flows where you need full user context in downstream services
Scenarios requiring per-resource checks (RBAC/ABAC) based on user identity and attributes

3️⃣ Service Account / Client Credentials

Description:

For service-to-service (S2S) calls, each service has its own client_id / client_secret and obtains a token via the Client Credentials Flow.

How it works:

Service A → IdP with client_id / client_secret → receives a service JWT
Service A → Service B using this token in the Authorization header
Service B validates the token and checks the permissions of Service A (not the end-user)

Pros:

Permissions are assigned to services, not users
Well-suited for batch jobs, background workers, daemons

Cons:

No end-user context (often needs to be combined with token propagation)
Storing secrets in services introduces secrets management risk

When to use:

Background jobs, schedulers, cron
Integrations between services where no end-user is directly involved

4️⃣ Authorization Patterns with Distributed Data (4 Strategies)

From Chris Richardson (microservices.io): used for fine-grained authorization when permissions are spread across multiple services.

Strategy	Description	Pros	Cons
Provide	All required claims (roles, tenant, relationships) are embedded into the JWT by IdP	Fast, fully stateless	JWT becomes huge, revocation is hard
Fetch	Service fetches permissions from other services on each request (REST/gRPC)	Always up-to-date data	Latency (N+1 calls), coupling to others
Replicate	Service keeps a local replica of foreign data (events/CQRS-based sync)	Fast local checks	Eventual consistency, complex replication
Delegate	Authorization is delegated to an external Authorization Service (OPA, Cerbos, Oso)	Centralized policies, handles complex logic	Dependency on AuthZ service, added latency

Delegate example:

A microservice calls the AuthZ service:

isAllowed(user=alice, action=delete, resource=order123) → YES/NO
The AuthZ service returns yes or no, and the microservice enforces the result.

5️⃣ Edge vs Service-Level Authorization
Description:
Two-layer authorization model:

Edge (Gateway): Coarse-grained checks: roles, scopes, rate limiting, tenant isolation
Service Level:Fine-grained checks: concrete permissions on specific resources

Pros:

Defense in depth — multiple layers of protection
The gateway filters out most invalid/unauthorized requests early

Cons:

Duplication of checks between gateway and services

When to use:

For all public APIs, Internet-facing systems, and multi-tenant platforms

6️⃣ Centralized Authorization Service
Description:
A separate service stores policies (e.g. Rego/OPA, Cedar/Cerbos) and answers questions like: allow?(user, action, resource) → true/false

Pros:

Can handle complex logic (ABAC, ReBAC, tenant isolation) in one place
Supports auditing, A/B testing of policies, GitOps workflows

Cons:

Adds latency to each authorization decision
Another single point of failure if not deployed in HA

When to use:

Enterprise systems with thousands of rules and users
Regulated industries where auditability and consistency of policies are critical

🔁 Delegate Pattern (Authorization Delegation) + OPA

Theory: The Distributed Permissions Problem

In a microservices architecture, permissions for a single resource are often spread across multiple services. For example, user Alice might be allowed to:

✅ Read her own orders (Order Service)
✅ Create payments for her own orders (Payment Service)
❌ Modify other users’ orders (Order Service)
✅ As a manager, see her team’s orders (User Service + Order Service combined)

A JWT can carry only static claims (roles, groups, basic attributes) — it does not know about:

Concrete relationships (owner of this order, member of this team)
Dynamic state (order status, project membership, org structure changes)

Solution: The microservice delegates the authorization decision to an external Authorization Service that knows all the rules and data needed.

How the Delegate Pattern Works

Flow:

Client → Order Service

DELETE /orders/123
Authorization: Bearer

Order Service extracts key claims from the JWT: { "userId": "alice", "roles": ["user"], "tenant": "acme" } 3.Order Service → AuthZ Service (delegated check): POST /authorize Content-Type: application/json

{
"principal": { "id": "alice", "roles": ["user"] },
"action": "delete",
"resource": { "type": "order", "id": "123" },
"context": { "tenant": "acme" }
}

AuthZ Service → response: { "allow": true, "reason": "user is owner of order" } or { "allow": false, "reason": "user is not owner and not manager" }
Order Service either performs or rejects the operation based on the AuthZ decision.

OPA (Open Policy Agent) as a Delegate Implementation

OPA is a Policy-as-Code engine that evaluates authorization policies written in the Rego language.

✅ Benefits of Delegate + OPA

✅ Complex logic: Handles ABAC, ReBAC, tenant isolation, workflow-dependent rules
✅ Centralized policies: One Rego policy set used by many services
✅ Auditability: You can log every authorization decision
✅ A/B testing of policies: Roll out policy changes without redeploying services
✅ GitOps-friendly: Policies live in Git and are deployed via CI/CD
✅ Polyglot support: OPA can be used from Go, Java, .NET, Node and more

❌ Drawbacks

❌ Latency: Adds ~50–200 ms per authorization call over the network
❌ Single point of failure: OPA must run in a highly available setup
❌ Complexity: Rego is a new language the team has to learn
❌ Data synchronization: Business data must be synced or exposed to OPA for decisions

🔁 Alternatives to OPA

Cerbos — managed/embedded policy engine, often simpler to integrate
OpenFGA (Google Zanzibar model) — ReBAC (relationships: user → document → viewer)
Permify — Zanzibar-style auth on PostgreSQL
Oso — policy language and engine with Python/Rust SDKs

🧭 When to Use the Delegate Pattern

Use Delegate + Policy-as-Code when:

✅ You have 10+ microservices with non-trivial permissions
✅ You are building a multi-tenant platform
✅ You work in regulated industries (fintech, healthcare, gov)
✅ You need strong audit/compliance guarantees

Avoid it when:

❌ You have simple CRUD apps with basic role-based access only

2026 status: Policy-as-Code (OPA/Cerbos) is considered an enterprise standard, especially in environments using GitOps and service meshes.

7️⃣ 2026 “Golden Standard”: Layered Approach

High-Level Architecture

External Clients
↓
API Gateway / BFF
(OAuth2/OIDC + JWT validation, coarse-grained auth)
↓
Microservices
(token propagation or service tokens)
↕
Microservice ↔ Microservice
(mTLS in a service mesh + fine-grained auth)
External clients → API Gateway

Gateway handles OAuth2/OIDC, validates JWTs, and enforces coarse-grained authorization (roles, scopes, tenant).

Gateway → Microservices

Uses token propagation (forwarding user JWT) or service tokens (Client Credentials) for internal calls.

Microservice ↔ Microservice

Runs over mTLS inside a service mesh, with fine-grained authorization:

Local RBAC/ABAC in each service, or

Delegated checks via a centralized AuthZ service (OPA/Cerbos/etc.).

✅ Pros

Covers all major scenarios (user-facing, S2S, batch, partners)
Enables zero-trust networking inside the cluster
Scales well horizontally with stateless tokens and mesh-based security

❌ Cons

Increased infrastructure complexity
Requires a mature DevOps/SRE culture and good observability This is effectively what companies like Netflix, Uber, DoorDash and other large-scale players run in production today.

💻 Minimal C# Example (ASP.NET Core + JWT)
Below is a minimal JWT authentication setup for a microservice built with ASP.NET Core 8/10 Web API (acting as an OAuth2 resource server behind a gateway).

Minimal JWT Setup in ASP.NET Core (8/10)

1️⃣ `Program.cs` — JWT Bearer Configuration

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

var builder = WebApplication.CreateBuilder(args);
var configuration = builder.Configuration;

builder.Services
    .AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    })
    .AddJwtBearer(options =>
    {
        // URL of your IdP (e.g. https://idp.example.com)
        options.Authority = configuration["Jwt:Authority"];
        // Audience = this API's identifier (aud claim)
        options.Audience = configuration["Jwt:Audience"];

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

            // If you are not using Authority/JWKS and rely on a symmetric key:
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(configuration["Jwt:Key"]!))
        };
    });

builder.Services.AddAuthorization();
builder.Services.AddControllers();

var app = builder.Build();

app.UseRouting();

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

app.MapControllers();

app.Run();

2️⃣ Controller with Role-Based Authorization

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;

[ApiController]
[Route("api/[controller]")]
public class OrdersController : ControllerBase
{
    // Any authenticated user
    [HttpGet]
    [Authorize]
    public IActionResult GetMyOrders()
    {
        var userId = User.FindFirst("sub")?.Value;
        // Load orders by userId...
        return Ok(/* orders */);
    }

    // Only users with the "admin" role
    [HttpDelete("{id:int}")]
    [Authorize(Roles = "admin")]
    public IActionResult DeleteOrder(int id)
    {
        // Delete order...
        return NoContent();
    }
}

In a real production system, these APIs would typically sit behind an API Gateway, which:

Validates tokens at the edge

Optionally enriches requests with user context

Forwards the token (or an internal token) to microservices

The tokens themselves are issued by an IdP such as Duende IdentityServer, Auth0, Azure AD B2C, or Keycloak.

🎯 Which Approach to Use When (Practical Guidance)

Decision Table for 2026

Scenario	Recommended Approach
SPA / mobile client + many microservices	OAuth2/OIDC + JWT via IdP and API Gateway
Public REST API for external clients	OAuth2 (auth code / client credentials) + JWT or opaque tokens
Internal service-to-service calls	mTLS in a service mesh + either user JWT propagation or service tokens
Small web app / semi-monolith	Sessions (cookies + session store), or JWT if microservices migration is planned
Simple batch / CLI integrations	API Keys or OAuth2 Client Credentials
Fintech, government, critical infrastructure	Combo: OIDC+JWT for users, mTLS for services, short-lived tokens, MFA, audit logging

For modern microservices with external clients, your default choice should be:

IdP + OAuth2/OIDC + JWT + API Gateway, with mTLS and short-lived tokens inside the cluster.
Keep sessions for simple / legacy web apps and internal admin panels, where microservices aren’t really needed yet.
Use API keys sparingly, for those services and scripts where a full OAuth2 setup would be overkill.

When designing your solution, consider not only security, but also resilience:

how painful will it be if IdP, gateway, session store, or PKI/mesh go down?

In 2026, this is just as important a design criterion as developer convenience.

Task Tracker Comparison 2025–2026: Which One for .NET/DevOps?з

Татьяна Кузнецова — Thu, 29 Jan 2026 13:53:10 +0000

"Effective time management is key to developer and team productivity" —
sounds official, but it perfectly captures project reality. Without a system, tasks blur, deadlines slip, and burnout creeps in: a huge chunk of time gets lost switching between tasks. Task trackers fix this — they visualize backlogs, prioritize (Eisenhower/MoSCoW), track time, and automate routine, boosting focus noticeably.

Year after year trying different task trackers, I keep asking: which one's most convenient? Has anything better appeared? Based on 2025 user reviews and roundups (G2, Reddit, Habr, RU blogs), leaders are Asana, Jira, ClickUp, Trello, Monday.com globally + YouGile, Yandex Tracker, Kaiten in the Russian-speaking segment.

Popularity in 2025

Global:

ClickUp leads growth (often #1 in PM rankings).
Jira dominates in IT/DevOps teams.
Trello and Asana stay popular for their simplicity.

Russia / RU segment:

Yandex Tracker, YouGile, Kaiten are frequently recommended for compliance, pricing, and self-hosting.
Jira is still a go-to option in many dev teams.
Habr articles often praise Russian tools for being on‑prem friendly.

On Reddit you’ll often see: “ClickUp is all-in-one, Jira is for serious dev work.”

Key Features Comparison

All of them cover the basics: Kanban, lists, deadlines, comments, and notifications. The real differences are in agile tooling, automation, AI, and integrations — that’s what affects time tracking, prioritization, and how painless your daily workflow feels.

Tool	Core Features	Advanced Features	Integrations
Asana	Boards, lists	Timeline, automations	1000+ (Slack, etc.)
Jira	Backlogs, sprints	Roadmaps, AI, advanced workflows	GitHub, Bitbucket
ClickUp	Hierarchy (spaces, lists), views	AI, time-tracking, goals	1000+ via native/Zapier
Trello	Simple Kanban boards	Power-ups, automations (Butler)	Google, Slack, others
Monday.com	Dashboards, boards	CRM, Gantt, automation	Zapier and many more
YouGile	Kanban, built-in chats	CRM-like features, messenger	Telegram, 1C
Yandex Tracker	Agile boards, queues	Deep Yandex ecosystem integration	Mail, Wiki, Tracker
Kaiten	Kanban, checklists	Automations, analytics	Bitrix, Telegram

Pricing (/user/month, annual billing)

Global tools mostly bill in USD, Russian tools — in RUB, often with self-host options.

Important about Jira Data Center:

Atlassian is sunsetting Data Center: new sales for new customers end March 30, 2026, renewals for existing customers are allowed until March 30, 2028, with full end-of-life (effectively read-only / end of support) in March 2029.

Tool	Free Plan	Premium (from, /user/mo)	Self-host / On‑prem
Asana	Up to 10 users	Starter from $10.99	No
Jira	Up to 10 users	Standard from $9.05	Data Center (EOL 2029)
ClickUp	Unlimited users	Unlimited from $7	No
Trello	Unlimited users	Standard from $5	No
Monday.com	Up to 2 users	Basic from $9	No
YouGile	Unlimited users	from 396 RUB	Yes, from ~695 RUB
Yandex Tracker	Up to 10 users	~258–495 RUB	Yes
Kaiten	Up to 10 users	~580 RUB	Yes

Mobile Apps (2025–2026)

All these tools have iOS/Android apps with solid ratings, typically in the 4.5–4.8/5 range. For time management “on the go”, that matters a lot: it’s your way to check the board in the subway, move a ticket to “In Progress”, or close a bug from your phone.

In short:

Asana — fast task creation and notifications, occasionally users mention sync glitches.
Jira — good for viewing issues and commenting; advanced filtering and configuration are still more convenient on desktop.
ClickUp — powerful views on mobile, but can feel overwhelming for new users.
Trello — probably the most touch-friendly Kanban; drag‑and‑drop just works.
Monday.com — convenient dashboards and high-level monitoring.
YouGile — intuitive chats + tasks in one app, rare freezes mentioned in reviews.
Yandex Tracker — quick status updates and task creation, well-tuned for Yandex ecosystem.
Kaiten — full boards with offline support; good fit when you need Kanban everywhere.

Role-Based Rankings

Developers / DevOps

If you care about sprints, Git integration, and CI/CD visibility:

Jira – strong agile tooling (sprints, backlogs, roadmaps) and first-class GitHub/Bitbucket integration.
Yandex Tracker – agile boards, self-host and MSSQL-friendly, good fit for Russian infrastructure.
ClickUp – lots of views, built-in time tracking, AI for writing and summarizing.
Kaiten – Kanban-centric with automations, suitable for product and DevOps teams.
Bitrix24 – heavy, but offers tasks plus CRM and comms in one place.

Managers / Leads

If you mostly watch progress, deadlines, and cross-team status:

Monday.com – dashboards, Gantt, portfolios; easy to present to stakeholders.
Asana – timelines and portfolios for project roadmaps.
YouGile – quick overviews plus team communication in one tool.
ClickUp – goals, time tracking, and reporting, if you’re ready for the learning curve.
Trello – simple visual overview for smaller teams and projects.

Freelancers / Small Teams

When you don’t want to overcomplicate it:

Trello – unlimited free, extremely simple Kanban.
ClickUp – generous free tier and “everything in one place” approach.
YouGile – chat + tasks, good for small Russian-speaking teams.

Communication‑Heavy Teams (IoT, music apps, etc.)

If your team lives in chat:

YouGile – built-in messenger tightly linked with tasks.
Bitrix24 – telephony, chats, tasks, CRM in one ecosystem.
Yandex Tracker – works well together with Yandex Mail, Wiki, etc.

Recommendations for .NET/DevOps in Russia

If you’re in the .NET/DevOps world:

Jira Cloud is still a very solid choice for GitHub integration and classic agile. Keep in mind the Data Center end-of-life if you were considering self-hosting.
Yandex Tracker and Kaiten are great local self-host options, friendly to Russian infrastructure, with MSSQL and good mobile apps.

My practical suggestion: start with the free tiers and mobile apps of 2–3 tools that fit your stack and team size. Run a real sprint or a small project in each — you’ll feel in a week which tracker actually saves you time instead of stealing it.

In my personal ranking, Jira still confidently holds the first place.
What about you — which task tracker do you enjoy using the most, and why?
This overview reflects the state of tools and pricing as of early 2026.

Smart Kitchen Shelf: .NET + ESP32 + AI for Full Inventory Automation. Part 1

Татьяна Кузнецова — Tue, 20 Jan 2026 13:39:11 +0000

With AI entering our lives, home automation and smart home systems have become much simpler and accessible to everyone. I've long wanted to create a system that would take most of the product management duties off my hands. This routine task eats up so much time that could be spent more productively.

The Idea: From Total Chaos to Automation

The ultimate goal is a system that automatically tracks all products in your home, knows their composition and expiration dates, auto-orders what's running low, and ideally even removes expired items (though that's still science fiction, as is automatic fridge organization). It should suggest menus based on family diets, allergies, taste preferences, and eating history.

But we have to start somewhere! For a long time, figuring out products, expiration dates, and composition without manual entry was a problem. One solution was barcode scanning, but... Different barcode databases, not always accessible, barcodes don't reveal composition, and bringing every product to the scanner isn't real automation.

But AI changes everything! Now we can recognize objects in photos, instantly find manufacturer info, composition, and there are even systems that find optimal prices! Life is getting better! That's what I was thinking just yesterday.

My immediate goal is a test project monitoring products in one cabinet first, then expanding to others and the fridge once debugged.

What We're Building On

Kitchen food cabinet 80×40×60 cm. Glass shelves (this is important).

Technical Foundation: ESP32-S3 + OV5640 Camera (No Tags Needed)

For full hands-free automation, I'm using ESP32-S3 with OV5640 camera module (5MP, fisheye lens 160-170° for complete shelf coverage).

Camera placement: Horizontally mounted above each glass shelf (20-30 cm above, 45° downward angle for full row visibility to the back wall), attached with double-sided tape or clips — this way they see through the glass without product obstruction (height up to 20 cm).

When the door opens (GPIO sensor), ESP captures a photo in 1 second, and AI (TensorFlow Lite Micro or YOLOv8-lite on edge) recognizes products: grains, cans, spices by shape, color, packaging. Accuracy after calibration (10 photos/product) — 92-98% for 50+ kitchen items, even with stacked rows.

One 60×40 cm shelf needs 1 ESP32-S3 camera (fisheye covers 100% without multiplexing), three shelves need 3 modules with WiFi bridge to central hub.

AI extrapolates occluded areas (back rows), counts quantities, reads expiration dates from labels (OCR on ESP-IDF). Data sent via MQTT to .NET backend.

I have Arduino — should I use it? No need: ESP32-S3 is self-sufficient (WiFi, GPIO, camera, powerful CPU/PSRAM for AI), simpler and cheaper for IoT without extra boards. Arduino works only for sensor testing, but loses to camera+AI in performance and connectivity.

.NET Backend + AI Agent Integration

ASP.NET Core backend receives photos from ESP32 (WiFi POST or MQTT), ML.NET for local vision model or cloud YOLO API.

C# agent (LangChain.NET) analyzes inventory:

Generates menus: "Chicken, rice, carrots → pilaf for 4, 450 kcal/serving"
Considers family: allergies, tastes (spicy for husband, gluten-free for child)
Auto-order: Ozon/Wildberries API integration for best prices

API endpoint example:

[HttpPost("analyze-shelf")]
public async Task<IActionResult> AnalyzeShelf(IFormFile image)
{
    var model = await _mlContext.Model.Load("yolov8_kitchen.zip", out _);
    var prediction = model.CreatePredictionEngine<ImageData, Prediction>(model).Predict(input);
    // Process: product list, quantities, dates
    var agent = new KitchenAgent(inventory, familyPrefs);
    var menu = agent.SuggestMeals();
    return Ok(new { inventory, menu });
}

💰 Cost Breakdown

Component	Price (RUB)	Notes
ESP32-S3 + OV5640 fisheye (x3)	2344	618 RUB/module + 200 RUB fisheye lens + 240 RUB shipping (or 900 RUB/unit on Ozon) [3]
3 glass shelves	2200	Tempered 6-8mm
Sensor + relay	500	GPIO auto-trigger
Total	5044	Compact, 160° coverage without blind spots

Prototype on ESP-IDF or MicroPython ready in a weekend: GPIO for sensor, MQTT to .NET API, Telegram bot for alerts ("Milk gone, buy 2L").

ESP32-S3 runs YOLO-lite onboard (50ms/frame), waiting for AliExpress parts — once they arrive, I'll assemble and write Part 2 with real tests and code.

❓ Have You Tried This?

Curious: has anyone built similar smart shelves with camera+AI fisheye? Did you get it working in practice?

Share in comments — experiences, repos, occlusion or accuracy issues!

This isn't sci-fi, it's a real step toward household automation with .NET + ESP32 + AI. Try it yourself — open source code (ESP32-CAM pantry on GitHub), hardware available on Ali.

Worth scaling to full kitchen? 🚀[3]

Part 1/2. Part 2 with real tests, code, and recognition accuracy — coming once cameras arrive from Ali!

dotnet #esp32 #ai #iot #smarthome #computervision #yolo #mlnet

Don't pull the entire dump if you only need a small piece

Татьяна Кузнецова — Sun, 11 Jan 2026 17:46:03 +0000

In one of my recent projects for a Canadian company, I was tasked with generating fairly complex PDF reports in a distributed data system.[file:54]

The report itself was based on data from just three tables – but those tables contained millions of rows.

The obvious problem: the database on dev/stage is huge.

Pulling a full backup (hundreds of GBs) to a local machine just to debug one reporting module is a great way to waste half a day and most of your SSD.

The naive approach: full backup or SSMS scripts

Most teams start with one of these options:

Restore a full database backup locally.
Use SSMS → Generate Scripts (Schema + Data) for the required tables.

Both options look reasonable on paper, but break down at scale:

A full backup:
- Takes hours to download and restore.
- Eats a massive chunk of disk space.
- Includes a lot of data you simply do not need for a specific test case.
SSMS “Generate Scripts” for tables with millions of rows:
- Tries to produce a gigantic INSERT script.
- Frequently freezes or dies with OutOfMemory.
- Even if the script is generated, executing it can take many hours.

At some point it becomes clear: we don’t need the whole mountain – just a slice of rock.

A better approach: surgical extraction with BCP

For SQL Server, my go‑to tool here is bcp (Bulk Copy Program).

Instead of moving an entire 200+ GB database around, I extract only the data slices needed for debugging and recreate them locally.

The idea is simple:

Keep the schema in source control (migrations, DDL scripts).
Use BCP to move only the relevant data between environments.

Why BCP beats SSMS for this use case

BCP is not new or flashy, but it shines when you need to move lots of rows quickly.

Key advantages:

Speed

BCP works with a binary stream in native format.

There’s no SQL text to parse, no giant INSERT statements.

Millions of rows can be exported/imported in minutes.
Stability

A console utility does not hang on a heavy UI operation or choke while rendering a huge script file.

It either runs fast or fails with a clear error.
Flexibility

You can export:
- A whole table, or
- The result of an arbitrary SELECT with joins and filters.

This means you can:

Export just the subset of data you need for a given test scenario.
Exclude sensitive columns or mask them directly in the SELECT.

Practical workflow: from prod slice to local debug

In the PDF-reporting case, the flow looked like this:

Prepare the schema locally

Apply migrations or run your DDL scripts to create the same tables locally.
No data yet, just structure.

Export the data slice from upstream environment

Example (conceptual):

   bcp "SELECT c.Id, c.Name, o.Id, o.Date, o.Total
        FROM dbo.Customers c
        JOIN dbo.Orders o ON o.CustomerId = c.Id
        WHERE o.Date >= '2025-01-01'"
        queryout orders_customers.dat -n -S your-server -T

bash
Notes:

queryout lets you export the result of a SELECT, not just a whole table.

-n uses native (binary) format — fast and compact.

-T uses trusted connection; replace with -U/-P if needed.

Import into local database

bcp dbo.OrdersCustomers in orders_customers.dat -n -S localhost -T

bash

You can split this into several files (per table) if it better matches your local schema.

Debug with realistic volumes

Now your local database contains:

The relevant tables.

The right data shape.

Realistic row counts (millions if needed).

But you never had to restore the full 200+ GB backup.

When you should consider this approach
This pattern works especially well when:

You have a huge SQL Server database in upper environments.

You need realistic data for:

Debugging complex business logic.

Reproducing production-only bugs.

Testing performance of reports or batch jobs.

You don’t want to:

Drag full backups around.

Rely on fragile UI exports.

Maintain a massive “test data” SQL script by hand.

BCP is not a silver bullet, but in scenarios where:

You know exactly which subset of data you need.

The volumes are too big for SSMS scripting.

You already have schema migrations in place.

…it can save you many hours per week and make local debugging much more pleasant.

How do you seed your local databases from large upstream environments?
Full backups, BACPACs, custom seeders, or something else?

Let me know — always curious about real-world workflows around this problem.

From 3+ Days to 3.8 Hours: Scaling a .NET CSV Importer for SQL Server

Татьяна Кузнецова — Sun, 04 Jan 2026 15:29:47 +0000

How changing requirements forced a 24x performance boost in a data pipeline.

The "Good Enough" Solution That Wasn't

Every project has that one task: "Just load this massive CSV into the database once, and we're done." That was my starting point. I had a 40 GB CSV file containing complex nested JSON structures (models, diagrams, hotspots, elements) that needed to be parsed and saved into a normalized SQL Server schema.

The first version of the importer was straightforward: read a row, parse the JSON, create entities, save to the DB. It worked, but it took over 3 days (~92 hours) to finish. For a one-time migration, this was painful but acceptable. You launch it on Friday, and hopefully, it's done by Monday.

Then the requirements changed.

The business decided this wasn't a one-off event. We needed to load several more files of similar size and potentially update them regularly. Suddenly, a 3-day runtime became a blocker. Loading a queue of files would take weeks, paralyzing analytics and development. The "naive" sequential importer was no longer just slow—it was unusable for the new workflow.

The Challenge: Why Was It Slow?

Parsing and inserting data sounds simple, but at scale (40 GB, millions of complex objects), the "standard" approach hits hard limits:

Sequential Processing: Reading lines and parsing JSON one by one left the CPU idle while waiting for the DB, and vice versa.
Database Round-Trips: Saving entities individually (or in tiny groups) caused massive overhead. The database spent more time managing transactions and network calls than actually storing data.
Memory Pressure: Loading full JsonDocument objects for every row created huge GC pressure.
Fragility: A single error after 2 days of processing could crash the whole pipeline, forcing a restart.

The Solution: High-Performance Architecture

To meet the new "multi-file" requirement, I redesigned the system to be parallel, batched, and resilient.

1. Controlled Parallelism with `SemaphoreSlim`

Instead of a single thread, I implemented a producer-consumer pattern using SemaphoreSlim to limit concurrency to 8 parallel workers.

Why: It saturates the CPU and DB connection pool just enough to be fast without choking the server. Unbounded parallelism (Parallel.ForEach) would have killed the database performance.
Safety: Each worker gets its own DbContext via IDbContextFactory, ensuring thread safety without lock contention.

2. Batch Inserts via EF Core (The Big Win)

This was the most critical change. Instead of context.Add(entity); context.SaveChanges(); inside the loop, the new system accumulates entities in memory and flushes them in batches of 100+ rows.

Impact: This reduces network round-trips by ~100x and drastically lowers transaction log overhead.

3. Architecture & SOLID Principles

To keep the code maintainable, I split the parsing logic into independent Processors, each responsible for a specific part of the JSON (e.g., ModelProcessor, DiagramProcessor).

SRP (Single Responsibility): Each processor handles only its slice of the domain.
DIP (Dependency Inversion): High-level services depend on abstractions (IEntityFactory, IUnitOfWork), making the system easy to test and extend.

4. Reliability Features

Retry Policies: Up to 25 retries for transient DB errors (deadlocks, timeouts).
Graceful Degradation: If one processor fails on bad data, it logs the error and continues, rather than crashing the entire import.
Optimized Parsing: Switched to JsonElement and TryGetProperty for faster, low-allocation JSON traversal.

The Results: 24x Faster

The performance jump was massive, turning a "weekend task" into a "lunch break task".

Metric	Original Version	Optimized Version	Improvement
Total Time (40 GB)	~92 hours (3.8 days)	~3.8 hours	~24x
Throughput	8–12 rows/sec	192–300 rows/sec	~25x
Time per 1000 rows	83–125 sec	3–5 sec	~25x
Parallelism	1 thread	8 workers	8x
Memory Usage	2 GB+	~400 MB	~5x

Key Takeaways

Context Matters: A 3-day script is fine once. It's fatal if you need to run it repeatedly. Always ask "how often will we run this?".
Batching is King: In EF Core, moving from single inserts to batching is often the single most effective performance upgrade you can make.
Parallelism Needs Limits: Throwing 100 threads at SQL Server will just slow it down. Finding the "sweet spot" (e.g., 8 workers) is key.
Resilience is a Feature: When running for hours, networks will blink and deadlocks will happen. Retry policies turn crashes into minor log warnings.

Future Plans

Add comprehensive tests (xUnit + Moq) with 85%+ coverage for all processors.
Profile individual pipeline stages to find the next bottleneck (likely JSON parsing CPU time).
Expose configuration (batch size, thread count) to adapt to different server specs dynamically.

Check out the code: Link to GitHub Repository

DevOps for 24 .NET Microservices: Prometheus Metrics + GitHub Actions CI/CD

Татьяна Кузнецова — Mon, 29 Dec 2025 12:53:52 +0000

How I set up advanced Prometheus metrics for 24 .NET microservices, automated CI/CD via GitHub Actions. From health checks to full observability.

From health checks to full observability

In the previous article, I already set up health checks in all 24 microservices, ready for Prometheus/Grafana.

But the client needed full metrics:

request counts by endpoints and status codes
P95/P99 response times
memory/CPU usage per service
specific SQL metrics for internal business processes
automated CI/CD pipeline

Step 1: Advanced Prometheus metrics in .NET + SQL

Added prometheus-net.AspNetCore NuGet to each microservice:

// Program.cs of each microservice (.NET 8)
var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddHealthChecks();
builder.Services.AddHttpClientMetrics();

var app = builder.Build();

app.UseRouting();
app.MapControllers();

app.MapHealthChecks("/health");

// Advanced HTTP metrics
app.UseHttpMetrics();
app.MapMetrics("/metrics"); // Prometheus scrapes here

Key metrics exposed on /metrics:
HTTP metrics (automatic)
http_requests_total_total{method="GET", endpoint="/api/applications", status="200"}
http_request_duration_seconds{quantile="0.95"}

.NET runtime
dotnet_total_memory_bytes

SQL metrics (via sql_exporter)
mssql_locks_wait_count_total
mssql_query_stats_total_duration_ms
mssql_database_size_bytes

sql_exporter for specific MSSQL business metrics:
prometheus.yml
scrape_configs:

job_name: 'mssql'
static_configs:

targets: ['sql_exporter:9187']
metrics_path: /metrics

Step 2: GitHub Actions CI/CD for 24 services

Single pipeline with matrix strategy:

name: CI/CD Microservices
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]

jobs:
test:
runs-on: ubuntu-latest
steps:

uses: actions/checkout@v4
name: Setup .NET 8 uses: actions/setup-dotnet@v4 with: dotnet-version: '8.0.x'
name: Test All Services run: | dotnet restore dotnet test --no-restore --collect:"XPlat Code Coverage"

build-push:
needs: test
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
strategy:
matrix:
service:

ApplicationService
JobService
AuthService # ... remaining 21 services steps:
uses: actions/checkout@v4
name: Build & Push Docker uses: docker/build-push-action@v5 with: context: ./src/${{ matrix.service }} push: true tags: myregistry/${{ matrix.service }}:latest

Step 3: Production stack (Windows services)

Prometheus + Grafana configured as Windows services — auto-start on server reboot:

✅ Prometheus (Windows Service) — scrapes /metrics from all 24 services + sql_exporter
✅ Grafana (Windows Service) — dashboards with auto-login for client
✅ Nginx (Windows Service) — reverse proxy
✅ MSSQL + sql_exporter — SQL business metrics

prometheus.yml (full scraping):
scrape_configs:

job_name: 'microservices'
static_configs:

targets:

'application-service:80'

'job-service:80'

... all 24 services
metrics_path: /metrics

job_name: 'mssql'
static_configs:

targets: ['sql_exporter:9187']

Grafana dashboards (SQL business metrics)

SQL metrics visualization in Grafana:
📊 HTTP Overview
├── Requests/sec by services
├── P95 latency
└── Error rates

📊 SQL Business Metrics (sql_exporter)
├── Database size (line chart)
├── Lock wait times (gauge)
├── Query duration TOP-10 (table)
└── Business KPIs (pie charts):
├─ Jobs completed today
├─ Active sessions by status
└─ Queue processing distribution

Evolution results

✅ Health checks → Full metrics — HTTP + .NET + SQL

✅ Automated CI/CD — 24 services in 5 minutes

✅ Production services — Prometheus/Grafana auto-start

✅ SQL business metrics — sql_exporter + pie charts in Grafana

Health Checks → HTTP Metrics → sql_exporter → Grafana Pie Charts
↓
GitHub Actions → Docker → Windows Services (Prometheus + Grafana)

Additional DevOps experience

🎯 New skills:

sql_exporter for MSSQL business metrics
Windows Services for Prometheus/Grafana
Grafana pie charts for KPI dashboards
GitHub Actions matrix (24 parallel builds)

✅ Worked perfectly:

app.UseHttpMetrics() — 2 lines of code
sql_exporter — ready-made SQL metrics out of the box

Code in repository

https://github.com/belochka1-04/WebApi_microservices/tree/main/

📁 devops/
├── prometheus.yml (24 services + sql_exporter)
├── .github/workflows/ci-cd.yml
├── docker-compose.prod.yml
└── windows-services/ (Prometheus + Grafana setup)

From Client Request to 24 .NET Microservices: My Solo Migration Journey

Татьяна Кузнецова — Mon, 29 Dec 2025 12:23:09 +0000

Backstory: the client's request

It all started with a fairly typical client request:

"I have a MySQL database with tables and data in Excel. I want a robust mega-system that scales, runs without downtime, and grows with the business. Ready to build it step by step, but need the right architecture from the start."

At that point, the client had MySQL tables, Excel data, and a general vision of how everything should work, plus a strong desire to "build it properly." No specific requirements for development speed, load, or SLA—just the understanding that they needed scalable architecture that wouldn't require a complete rebuild in a year or two.

Stage 1: MVP with Web API + console apps

First stage — quickly build a working prototype:

Migrated data from MySQL and Excel to MSSQL (client chose SQL Server as better suited for .NET ecosystem);
Built one Web API on .NET with core CRUD operations;
Added several console applications for background tasks (processing, import, reports).

Initial architecture looked like this:
Console Apps (batch jobs)
↓
Web API (.NET + EF Core)
↓
MSSQL (data from MySQL + Excel)

This approach delivered a working product to the client in 2-3 weeks. The system processed data, showed results, ran on the server.

Stage 2: monolith pain points

The client kept adding requirements and complicating logic, while I realized: continuing to pile everything into one service would just delay the inevitable rebuild. Classic monolith problems emerged:

Every change = restart of the entire service;
Impossible to scale selectively;
Downtime risk — a bug in one area could crash the whole system;
Maintenance complexity — all business logic in one place.

Solution: gradual migration to microservices

Once the final logic was shaped and it became clear how the end system should work, I decided to migrate to microservices architecture gradually, keeping the system operational at every step. Principle: "strangler pattern" — the monolith gradually gets "strangled," while functionality moves to new services.

Key migration principles:

Start with business boundaries;
Each new service must be fully autonomous (Docker, tests, health checks);
Keep system operational after each step.

Migration result: 24 microservices

I single-handedly transformed the monolith into 24 independent Web API microservices:

Project description

Monolithic .NET application migration to microservices architecture: extracted 24 Web API microservices (Auth, Application, Job, Mask, User, etc.), each with its own bounded context and dedicated controllers. Inter-service communication implemented via RabbitMQ (event bus for async task-related events and entities) and HTTP (typed HttpClient + IHttpClientFactory, service URLs and routes externalized to appsettings.json).[file:1]

Data storage in MSSQL via EF Core, API access secured with JWT authentication, health checks, Swagger, and centralized logging (Serilog, NLog) configured.[file:1]

Full project code: https://github.com/belochka1-04/WebApi_microservices [file:1]

Status and completed tasks

What I've already done:[file:1]

✅ Extracted 24 Web API services with separate bounded contexts and contracts
✅ Added unit/integration tests + Docker support to ApplicationService
✅ Implemented health checks for all microservices (ready for Prometheus/Grafana)
✅ Set up RabbitMQ and typed HttpClient communication

In progress/planned:[file:1]

🔄 Expand test coverage to remaining services
🔄 Standardize Docker containers across all 24 services
🔄 Integrate Prometheus + Grafana for full observability

Tech stack

Complete project stack:[file:1]

Platform: .NET 8, ASP.NET Core Web API
Language: C#
Architecture: microservices (24 services), REST API, bounded contexts, SOLID, DI/IoC
Data access: Entity Framework Core, SQL Server (MSSQL), migrations
Communication: HTTP (typed HttpClient), RabbitMQ (event bus)
Security: JWT authentication
Logging: Serilog, NLog, health checks
API docs: Swagger/OpenAPI
Containerization: Docker (Dockerfile, docker-compose)
Testing: unit/integration tests

Key migration lessons (from a solo developer)

What worked great:

Gradual approach kept the system running
Docker + health checks from day one saved tons of time
DTOs and explicit contracts prevented mass refactoring during DB changes
RabbitMQ was perfect for async scenarios

What was trickier:

Splitting shared MSSQL tables across services (ownership boundaries)
Managing 24 Docker containers locally (docker-compose to the rescue)
Realizing microservices = code + DevOps (monitoring, logs, deployment)

What's next

The system is now production-ready, but full observability awaits:

Prometheus + Grafana for health check and performance metrics
Unified docker-compose for all 24 services + MSSQL + RabbitMQ
CI/CD pipeline for automated deployments

In the next article, I'll cover setting up this monitoring stack on Windows with Telegram alerts.

Forem: Татьяна Кузнецова

Authorization methods in .NET microservices

Theory: Authentication vs Authorization in Microservices

Main Authorization Approaches in Microservices

📈 Approach Features & 2026 Trends

Centralized IdP/Auth-hub + Resource Servers Pattern

Quick Overview of Approaches

1️⃣ Sessions (Cookies + Server-Side Sessions)

How It Works

✅ Advantages

❌ Disadvantages & Microservices Issues

When to Use

2️⃣ JWT (JSON Web Token)

How It Works

✅ Advantages

❌ Disadvantages

When to Use

3️⃣ OAuth2 / OIDC

How It Works

Main Flows Used with Microservices

Token Types

✅ Advantages

❌ Disadvantages

When to Use

4️⃣ API Keys

How It Works

✅ Advantages

❌ Disadvantages

When to Use

5️⃣ mTLS (Mutual TLS)

How It Works

mTLS in a Service Mesh (e.g., Istio)

✅ Advantages

❌ Disadvantages

When to Use

🔄 Authorization Flows: Client → Gateway → Microservices

1️⃣ Client → IdP → API Gateway → Microservices (OAuth2/OIDC + JWT)

🔐 Authentication at IdP (SSO)

📥 Client → API Gateway

📡 Gateway → Microservices

🧩 Authorization Inside Microservices

2️⃣ Service-to-Service (S2S) Authorization

Pattern 1: Propagation (User Token Forwarding)

Pattern 2: Service Account / Client Credentials

Pattern 3: mTLS in the Mesh

⚙️ Resilience: How Painful Are Failures?

1️⃣ OAuth2/OIDC + JWT

2️⃣ JWT Without a Central IdP

3️⃣ Sessions

4️⃣ API Keys

5️⃣ mTLS

🧩 Authentication & Authorization Patterns in Microservices

1️⃣ API Gateway / BFF as the Authentication Entry Point

2️⃣ Token Propagation

3️⃣ Service Account / Client Credentials

4️⃣ Authorization Patterns with Distributed Data (4 Strategies)

🔁 Delegate Pattern (Authorization Delegation) + OPA

Theory: The Distributed Permissions Problem

How the Delegate Pattern Works

OPA (Open Policy Agent) as a Delegate Implementation

✅ Benefits of Delegate + OPA

❌ Drawbacks

🔁 Alternatives to OPA

🧭 When to Use the Delegate Pattern

7️⃣ 2026 “Golden Standard”: Layered Approach

High-Level Architecture

Minimal JWT Setup in ASP.NET Core (8/10)

1️⃣ Program.cs — JWT Bearer Configuration

🎯 Which Approach to Use When (Practical Guidance)

Decision Table for 2026

Task Tracker Comparison 2025–2026: Which One for .NET/DevOps?з

Popularity in 2025

Key Features Comparison

Pricing (/user/month, annual billing)

Mobile Apps (2025–2026)

Role-Based Rankings

Developers / DevOps

Managers / Leads

Freelancers / Small Teams

Communication‑Heavy Teams (IoT, music apps, etc.)

1️⃣ `Program.cs` — JWT Bearer Configuration

1. Controlled Parallelism with `SemaphoreSlim`