A deep dive into JWT authentication, AES-256-GCM encryption, SignalR, and production security patterns.
Introduction
Real-time messaging apps are everywhere, but most tutorials gloss over the hard parts — the security. In this post I’ll walk you through SecureChat, a production-grade messaging app I built with .NET 8 and Angular 18. By the end you’ll understand:
- How to encrypt messages at rest using AES-256-GCM
- How to build a JWT + rotating refresh token authentication flow
- How to wire up SignalR with a Redis backplane for real-time delivery
- How to implement a silent token refresh interceptor in Angular
- How to layer in rate limiting, security headers, and an audit trail
The full source is on GitHub: github.com/naimulkarim/SecureChat
Architecture Overview
Before we dive into code, here’s the full picture:
┌─────────────────────────────────────────────┐
│ Angular 18 Frontend │
│ Auth guard · Chat module · JWT interceptor│
└──────────────────┬──────────────────────────┘
│ HTTPS + WSS (TLS 1.3)
┌──────────────────▼──────────────────────────┐
│ .NET 8 Web API │
│ Auth API · Messages API · SignalR Hub │
│ Rate limiting · JWT · Security headers │
└────┬──────────────────┬───────────────┬─────┘
│ │ │
┌────▼────┐ ┌───────▼──────┐ ┌────▼─────┐
│SQL Server│ │ Redis │ │ Azure │
│Users/Msgs│ │Cache/Backpl. │ │ Blobs │
└──────────┘ └──────────────┘ └──────────┘
The key design decisions:
-
Short-lived JWTs (15 min) limit the blast radius if a token is stolen
-
Rotating refresh tokens mean a stolen refresh token can only be used once
-
AES-256-GCM encrypts every message before it hits the database
-
Redis backplane allows the SignalR hub to scale across multiple API instances
-
Per-user SignalR groups deliver messages to all of a user’s devices simultaneously
Part 1 — The .NET 8 Backend
Setting up Program.cs
The entry point wires together every security concern. Let me break it down section by section.
JWT Authentication
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
options.TokenValidationParameters = new TokenValidationParameters
{
ValidateIssuerSigningKey = true,
IssuerSigningKey = new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(jwtKey)),
ValidateIssuer = true,
ValidIssuer = builder.Configuration["Jwt:Issuer"],
ValidateAudience = true,
ValidAudience = builder.Configuration["Jwt:Audience"],
ValidateLifetime = true,
ClockSkew = TimeSpan.Zero // ← no grace period on expiry
};
// SignalR WebSocket upgrades can't send headers,
// so we read the token from the query string instead
options.Events = new JwtBearerEvents
{
OnMessageReceived = ctx =>
{
var token = ctx.Request.Query["access_token"];
if (!string.IsNullOrEmpty(token) &&
ctx.HttpContext.Request.Path.StartsWithSegments("/hubs"))
ctx.Token = token;
return Task.CompletedTask;
}
};
});
The ClockSkew = TimeSpan.Zero is intentional. The default is 5 minutes, meaning a “15-minute” token actually lives for 20 minutes. That’s an unnecessary exposure window.
The OnMessageReceived event is needed because WebSocket upgrade requests can’t carry Authorization headers — the browser spec doesn’t allow it. So the Angular client appends the JWT as a query parameter only for hub connections.
Rate Limiting
builder.Services.AddRateLimiter(opt =>
{
opt.AddFixedWindowLimiter("message", lim =>
{
lim.Window = TimeSpan.FromMinutes(1);
lim.PermitLimit = 60;
});
opt.AddFixedWindowLimiter("auth", lim =>
{
lim.Window = TimeSpan.FromMinutes(5);
lim.PermitLimit = 10; // max 10 login attempts per 5 min
});
});
Auth endpoints get a stricter limit to slow down brute-force attacks. Message endpoints are generous enough for normal usage but will stop a script flooding the server.
Security Headers
app.Use(async (ctx, next) =>
{
ctx.Response.Headers.Append("X-Content-Type-Options", "nosniff");
ctx.Response.Headers.Append("X-Frame-Options", "DENY");
ctx.Response.Headers.Append("X-XSS-Protection", "1; mode=block");
ctx.Response.Headers.Append("Referrer-Policy", "no-referrer");
ctx.Response.Headers.Append("Content-Security-Policy",
"default-src 'self'; connect-src 'self' wss:");
await next();
});
These headers are cheap to add and block an entire category of attacks — MIME sniffing, clickjacking, and cross-site scripting.
Authentication Service — JWT + BCrypt + Refresh Tokens
The AuthService handles the full auth lifecycle.
Registration
public async Task<AuthResult> RegisterAsync(RegisterRequest req)
{
if (await _db.Users.AnyAsync(u => u.Email == req.Email.ToLower()))
return AuthResult.Fail("Email already registered.");
var user = new User
{
Id = Guid.NewGuid().ToString(),
Email = req.Email.ToLower().Trim(),
DisplayName = req.DisplayName.Trim(),
PasswordHash = BCrypt.Net.BCrypt.HashPassword(req.Password, workFactor: 12),
CreatedAt = DateTime.UtcNow,
};
_db.Users.Add(user);
await _db.SaveChangesAsync();
await _audit.LogAsync("auth.register", user.Id, null);
return await IssueTokensAsync(user);
}
Work factor 12 for BCrypt means ~250ms to hash a password on modern hardware — fast enough for users, slow enough to make brute-forcing impractical.
JWT Generation
private string GenerateJwt(User user)
{
var key = new SymmetricSecurityKey(
Encoding.UTF8.GetBytes(_config["Jwt:Key"]!));
var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);
var claims = new[]
{
new Claim(ClaimTypes.NameIdentifier, user.Id),
new Claim(ClaimTypes.Email, user.Email),
new Claim(ClaimTypes.Name, user.DisplayName),
new Claim(JwtRegisteredClaimNames.Jti, Guid.NewGuid().ToString()),
};
var token = new JwtSecurityToken(
issuer: _config["Jwt:Issuer"],
audience: _config["Jwt:Audience"],
claims: claims,
expires: DateTime.UtcNow.AddMinutes(15),
signingCredentials: creds);
return new JwtSecurityTokenHandler().WriteToken(token);
}
The Jti (JWT ID) claim is a unique identifier for each token. This is what lets you build a token blocklist if you ever need to revoke individual tokens before expiry.
Rotating Refresh Tokens
public async Task<AuthResult> RefreshAsync(string refreshToken)
{
var stored = await _db.RefreshTokens
.Include(r => r.User)
.FirstOrDefaultAsync(r => r.Token == refreshToken && !r.IsRevoked);
if (stored is null || stored.ExpiresAt < DateTime.UtcNow)
return AuthResult.Fail("Invalid or expired refresh token.");
stored.IsRevoked = true; // ← revoke old token immediately
await _db.SaveChangesAsync();
return await IssueTokensAsync(stored.User); // ← issue fresh pair
}
Rotation means every successful refresh invalidates the old token and issues a new one. If an attacker steals a refresh token and uses it, the legitimate user’s next refresh will detect the conflict (token already revoked) and you can force a full re-login.
Encryption Service — AES-256-GCM
This is the most security-critical piece of the backend.
public string Encrypt(string plaintext)
{
// Fresh 96-bit nonce for every single message
var nonce = new byte[AesGcm.NonceByteSizes.MaxSize];
RandomNumberGenerator.Fill(nonce);
var plaintextBytes = Encoding.UTF8.GetBytes(plaintext);
var ciphertext = new byte[plaintextBytes.Length];
var tag = new byte[AesGcm.TagByteSizes.MaxSize]; // 128-bit auth tag
using var aes = new AesGcm(_key, tag.Length);
aes.Encrypt(nonce, plaintextBytes, ciphertext, tag);
// Pack: [nonce 12B][tag 16B][ciphertext nB]
var combined = new byte[nonce.Length + tag.Length + ciphertext.Length];
Buffer.BlockCopy(nonce, 0, combined, 0, nonce.Length);
Buffer.BlockCopy(tag, 0, combined, nonce.Length, tag.Length);
Buffer.BlockCopy(ciphertext, 0, combined, nonce.Length + tag.Length, ciphertext.Length);
return Convert.ToBase64String(combined);
}
Why AES-256-GCM specifically?
-
AES-256 — the key length (256 bits) is computationally infeasible to brute-force
-
GCM mode — provides both confidentiality (encryption) and integrity (the 128-bit authentication tag). If anyone tampers with the ciphertext in the database, decryption throws an exception rather than silently returning garbage
-
Fresh nonce per message — reusing a nonce with the same key in GCM mode catastrophically breaks security. We use
RandomNumberGenerator.Fill (cryptographically secure) for each encryption call
The nonce and tag are packed together with the ciphertext so decryption is self-contained — no separate columns needed.
SignalR Hub
[Authorize]
public class ChatHub : Hub
{
public override async Task OnConnectedAsync()
{
var userId = GetUserId();
// Each user gets a personal group across all their devices
await Groups.AddToGroupAsync(Context.ConnectionId, $"user:{userId}");
await _audit.LogAsync("hub.connected", userId,
Context.GetHttpContext()?.Connection.RemoteIpAddress?.ToString());
await base.OnConnectedAsync();
}
public async Task SendMessage(SendMessageRequest request)
{
if (string.IsNullOrWhiteSpace(request.Content) || request.Content.Length > 4000)
throw new HubException("Invalid message content.");
var senderId = GetUserId();
var saved = await _messages.SaveAsync(senderId, request);
// Fan out to every participant's group (covers multi-device)
foreach (var participantId in saved.ParticipantIds)
{
await Clients.Group($"user:{participantId}")
.SendAsync("ReceiveMessage", saved);
}
}
public async Task SendTyping(string conversationId, bool isTyping)
{
var userId = GetUserId();
var participants = await _messages.GetParticipantsAsync(conversationId, userId);
foreach (var participantId in participants.Where(p => p != userId))
{
await Clients.Group($"user:{participantId}")
.SendAsync("TypingIndicator",
new { conversationId, userId, isTyping });
}
}
}
A few design decisions worth noting:
Personal groups vs connection IDs. We add each connection to user:{userId} instead of tracking individual ConnectionId values. This means if a user has two browser tabs open, both get the message without any extra code. If you used ConnectionId you’d need a lookup table mapping users to connections.
Typing indicators are never persisted. They’re pure ephemeral SignalR events — no database write, no message history. They disappear the moment the connection drops.
HubException for client-visible errors. Regular C# exceptions become generic 500-style errors on the client. HubException propagates the message string to the caller, which lets Angular show a human-readable error.
Part 2 — The Angular 18 Frontend
JWT Interceptor with Silent Refresh
This is the piece most tutorials get wrong. The naive approach — refresh on 401, retry — breaks badly when multiple requests expire simultaneously. Our interceptor queues concurrent requests while a refresh is in flight.
let isRefreshing = false;
const refreshSubject = new BehaviorSubject<string | null>(null);
export const authInterceptor: HttpInterceptorFn = (req, next) => {
const auth = inject(AuthService);
const token = auth.accessToken();
const addToken = (r: typeof req, t: string) =>
r.clone({ setHeaders: { Authorization: `Bearer ${t}` } });
const request = token ? addToken(req, token) : req;
return next(request).pipe(
catchError((err: HttpErrorResponse) => {
if (err.status !== 401 || req.url.includes('/auth/'))
return throwError(() => err);
if (isRefreshing) {
// Another request is already refreshing — wait for it
return refreshSubject.pipe(
filter((t): t is string => t !== null),
take(1),
switchMap(t => next(addToken(req, t)))
);
}
isRefreshing = true;
refreshSubject.next(null); // signal "refreshing in progress"
return auth.refresh$().pipe(
switchMap(newToken => {
isRefreshing = false;
refreshSubject.next(newToken); // unblock queued requests
return next(addToken(req, newToken));
}),
catchError(refreshErr => {
isRefreshing = false;
auth.logout();
return throwError(() => refreshErr);
})
);
})
);
};
Walk through the flow:
- Request goes out with the current JWT
- Server returns 401 (token expired)
- If no refresh is in progress, start one and set
isRefreshing = true
- All other requests that 401 in the meantime subscribe to
refreshSubject and wait
- When refresh succeeds,
refreshSubject.next(newToken) unblocks all queued requests
- Each queued request clones itself with the new token and retries
Without this queuing, three simultaneous expired requests would trigger three parallel refresh calls, the second and third would fail (token already rotated), and the user would be logged out unexpectedly.
SignalR Chat Service with Angular Signals
@Injectable({ providedIn: 'root' })
export class ChatService {
// Reactive state using Angular 18 signals
messages = signal<Message[]>([]);
conversations = signal<Conversation[]>([]);
typingUsers = signal<TypingIndicator[]>([]);
connected = signal(false);
// Derived state — no manual subscription management
unreadCount = computed(() =>
this.conversations().reduce((sum, c) => sum + c.unreadCount, 0)
);
async connect(): Promise<void> {
this.hub = new signalR.HubConnectionBuilder()
.withUrl(`${environment.apiUrl}/hubs/chat`, {
accessTokenFactory: () => this.auth.accessToken() ?? '',
transport: signalR.HttpTransportType.WebSockets,
skipNegotiation: true,
})
.withAutomaticReconnect([0, 2000, 5000, 10000, 30000])
.build();
this.hub.on('ReceiveMessage', (msg: Message) => {
this.messages.update(msgs => [...msgs, msg]);
this.conversations.update(convs =>
convs.map(c =>
c.id === msg.conversationId
? { ...c, lastMessage: msg, unreadCount: c.unreadCount + 1 }
: c
)
);
});
// ...
await this.hub.start();
this.connected.set(true);
}
}
accessTokenFactory is a function, not a value. SignalR calls it on every reconnect attempt, so it will always pick up the freshest token (including any that were silently refreshed by the interceptor).
withAutomaticReconnect([0, 2000, 5000, 10000, 30000]) defines a custom backoff schedule — immediate retry, then 2s, 5s, 10s, 30s. After exhausting this list SignalR stops retrying, which lets you show a “connection lost” UI rather than hammering the server forever.
Using Angular signals instead of RxJS BehaviorSubject keeps the state management simple — components read chatService.messages() directly in their templates and Angular handles change detection automatically.
Part 3 — Security Checklist
Here’s every security mechanism in the app and why it’s there:
| Threat |
Mitigation |
| Password database breach |
BCrypt, work factor 12 |
| Token theft |
JWT expiry 15 min, ClockSkew = Zero
|
| Refresh token theft |
Server-side rotation — stolen token is single-use |
| Eavesdropping in transit |
HTTPS + WSS enforced, TLS 1.3 |
| Database breach (messages) |
AES-256-GCM at rest |
| GCM nonce reuse |
RandomNumberGenerator.Fill per message |
| Message tampering |
GCM authentication tag — tampered ciphertext throws |
| Brute-force login |
Rate limit: 10 attempts / 5 min |
| Message flooding |
Rate limit: 60 messages / min |
| Clickjacking |
X-Frame-Options: DENY |
| MIME sniffing |
X-Content-Type-Options: nosniff |
| Unauthorized hub access |
[Authorize] attribute, JWT validated on upgrade |
| Hub conversation access |
Server-side participant check before join/deliver |
| XSS |
Content-Security-Policy: default-src 'self' |
| Forensics / incident response |
Append-only audit log on every auth event |
Part 4 — Running It Locally
# Clone
git clone https://github.com/naimulkarim/SecureChat.git
cd SecureChat
# Generate secrets
openssl rand -base64 32 # → Encryption:Key
openssl rand -base64 64 # → Jwt:Key
# Backend
cd SecureChat.API
# Add secrets to appsettings.Development.json (never commit this file)
dotnet ef database update
dotnet run
# Frontend (new terminal)
cd ../secure-chat-ui
npm install
ng serve
Navigate to https://localhost:4200.
What’s Next
There are a few things I’d add before calling this truly production-ready:
Key management — move the AES key and JWT secret out of appsettings.json and into Azure Key Vault (or AWS Secrets Manager). The current setup is fine for local dev but secrets should never live in a config file in a real deployment.
Client-side encryption — the current model encrypts at the server before writing to the DB. True end-to-end encryption (where even the server can’t read messages) requires encrypting on the client with the recipient’s public key. This would involve WebCrypto API on the Angular side and a public key exchange flow.
Message deletion / expiry — a GDPR-friendly implementation needs the ability to delete or expire messages, with the encrypted blobs actually removed from storage.
Push notifications — when the user isn’t connected to the hub, they need push notifications. Web Push API + a service worker can deliver notifications even when the tab is closed.
Conclusion
The patterns in this post — short-lived JWTs with rotating refresh tokens, AES-GCM encryption at rest, request queuing during token refresh, and per-user SignalR groups — are the foundations of any serious real-time app. None of them are particularly exotic, but getting all the details right (nonce freshness, clock skew, refresh token rotation, concurrent refresh queuing) makes the difference between a demo and something you’d trust with real user data.
The full source is at github.com/naimulkarim/SecureChat. PRs and issues welcome.
Tags: dotnet angular security signalr webdev csharp typescript
