Implementare corectă (nu copy-paste)
Seria: Security by Design în .NET: De la JWT la Certificate-based Authentication
În articolul anterior am explicat cum funcționează JSON Web Tokens (JWT) și cum validează ASP.NET Core semnătura.
Problema este că JWT-urile sunt stateless.
Odată emis un token:
-
serverul nu îl mai poate revoca ușor
-
tokenul rămâne valid până la expirare
-
dacă este furat → atacatorul îl poate folosi
De aceea sistemele moderne folosesc Refresh Tokens.
🔐 Ce este un Refresh Token
Un Refresh Token este un token pe termen lung, folosit pentru a obține un nou Access Token fără ca utilizatorul să se logheze din nou.
Fluxul tipic:
1️⃣ User se autentifică
2️⃣ Server emite:
-
Access Token (ex: 10 minute)
-
Refresh Token (ex: 7 zile)
3️⃣ Când Access Token expiră:
Clientul trimite:
<code>POST /auth/refresh</code>
cu Refresh Token.
Serverul verifică tokenul și emite un nou Access Token.
🔁 Token Rotation (practica modernă)
Un refresh token nu trebuie reutilizat.
De fiecare dată când este folosit:
1️⃣ Serverul invalidează tokenul vechi
2️⃣ Creează un refresh token nou
3️⃣ Returnează Access Token + Refresh Token nou
Flux:
RT1 -> folosit -> invalidat
↓
RT2 -> folosit -> invalidat
↓
RT3
Beneficiu major: Dacă un atacator fură RT1, dar userul folosește deja RT2 → sistemul detectează atacul.
🧱 Schema corectă de bază de date
Un Refresh Token trebuie stocat în DB. Exemplu simplificat:
CREATE TABLE RefreshTokens
(
Id UNIQUEIDENTIFIER PRIMARY KEY,
UserId UNIQUEIDENTIFIER NOT NULL,
TokenHash NVARCHAR(200) NOT NULL,
CreatedAt DATETIME2 NOT NULL,
ExpiresAt DATETIME2 NOT NULL,
RevokedAt DATETIME2 NULL,
ReplacedByTokenId UNIQUEIDENTIFIER NULL,
CreatedByIp NVARCHAR(50)
);
Important:
✔ tokenul este hash-uit
✔ nu stochezi tokenul raw
🔒 Model C# pentru Refresh Token
public class RefreshToken
{
public Guid Id { get; set; }
public Guid UserId { get; set; }
public string TokenHash { get; set; }
public DateTime CreatedAt { get; set; }
public DateTime ExpiresAt { get; set; }
public DateTime? RevokedAt { get; set; }
public Guid? ReplacedByTokenId { get; set; }
public string CreatedByIp { get; set; }
public bool IsActive =>
RevokedAt == null && DateTime.UtcNow < ExpiresAt;
}
🧠 Endpoint Refresh în ASP.NET Core
Exemplu simplificat:
[HttpPost("refresh")]
public async Task<IActionResult> Refresh(RefreshRequest request)
{
var token = await _repo.GetByTokenHash(request.RefreshToken);
if (token == null || !token.IsActive)
return Unauthorized();
var newAccessToken = _jwtService.GenerateAccessToken(token.UserId);
var newRefreshToken = _tokenService.CreateRefreshToken(token.UserId);
token.RevokedAt = DateTime.UtcNow;
token.ReplacedByTokenId = newRefreshToken.Id;
await _repo.SaveChanges();
return Ok(new
{
accessToken = newAccessToken,
refreshToken = newRefreshToken.Token
});
}
🚨 Detectarea Reuse Attack
Un reuse attack apare când un refresh token deja invalidat este folosit din nou.
Scenariu:
1️⃣ User primește RT1
2️⃣ Atacatorul fură RT1
3️⃣ User folosește RT1 → primește RT2
4️⃣ Atacatorul încearcă RT1
Serverul detectează:
<code>RT1.RevokedAt != null</code>
Acțiune recomandată:
-
revoci toate tokenurile utilizatorului
-
forțezi reautentificarea
⏳ Sliding vs Absolute Expiration
Există două strategii.
Sliding Expiration
Tokenul se prelungește la fiecare refresh.
Exemplu:
Refresh token = 7 zile
User face refresh zilnic
→ tokenul continuă să fie valid
Avantaj:
✔ experiență bună pentru user
Dezavantaj: ⚠ sesiuni foarte lungi
Absolute Expiration
Tokenul expiră definitiv după o perioadă fixă. Exemplu:
Max lifetime = 30 zile
Chiar dacă faci refresh: → după 30 zile trebuie login.
🛡️ Best Practices Refresh Tokens
✔ Hash token în DB
✔ Token rotation obligatoriu
✔ Revocation list
✔ Detect reuse attack
✔ IP logging
✔ Device tracking
✔ Expirare limitată
✔ Token random lung (256 bits)
🔐 Unde se stochează Refresh Token pe client?
Recomandat:
HttpOnly Secure Cookie
Nu în:
❌ LocalStorage
❌ SessionStorage
Motiv: XSS poate fura tokenul.
🧱 Arhitectură modernă
Client (SPA / Blazor)
Access Token -> memorie
Refresh Token -> HttpOnly cookie
Server:
JWT stateless
Refresh Tokens stateful (DB)
Acesta este modelul folosit de majoritatea sistemelor enterprise.
🎯 Concluzie
JWT singur nu este suficient. Refresh Tokens rezolvă:
✔ expirarea scurtă a tokenurilor
✔ sesiuni persistente
✔ revocarea accesului
✔ detectarea atacurilor
Dar doar dacă sunt implementate corect.
