JWT login — access, refresh token আর React-এ সংযোগ

১ · JWT কখন মানায়, কখন session-ই সহজ

পর্ব ৪৫-এ (Session-ভিত্তিক login) server একটি এলোমেলো ID দেয়, আর তথ্য থাকে store-এ। এখানে দেখব অন্য পথ, JWT, যেখানে তথ্য স্বাক্ষর করা অবস্থায় token-এর ভেতরেই থাকে। Token-এর তত্ত্ব, RFC-র নিয়ম আর cookie flag-এর ব্যাখ্যা আছে সাইবার নিরাপত্তা কোর্সের Session আর token পর্বে. সেটি আমরা আবার পড়াব না। এখানে আমরা বাজারঘরের জন্য জিনিসটি বানাব।

একটি কথা সৎভাবে বলা দরকার। এই পর্বের নকশায় refresh token database-এ থাকে। তাই “JWT মানে database লাগে না” কথাটি এখানে সত্য নয়। লাভ হলো প্রতিটি API request-এ database ডাকতে হয় না, শুধু কয়েক মিনিট পরপর একবার। সম্প্রদায়ে এই নিয়ে মতভেদ আছে। অনেক অভিজ্ঞ প্রকৌশলী সাধারণ web app-এ JWT না নিতেই বলেন। বাজারঘরে একটি web অ্যাপ আর একটি মোবাইল অ্যাপ একই API ডাকবে, তাই আমরা JWT বেছে নিচ্ছি।

২ · একটি JWT খুলে দেখা

JWT-তে তিনটি টুকরো থাকে, মাঝে ডট: header, payload আর signature. প্রথম দুটি শুধু base64url encoding. তৃতীয়টি গোপন key দিয়ে প্রথম দুটির ওপর হিসাব করা HMAC. পরের অংশে বানানো ল্যাবের একটি token decodeProtectedHeader আর decodeJwt দিয়ে খুলেছি। মানগুলো নকল।

// সত্যিকারের run, jose 6.2.14, src/verify-cases.ts
header  { alg: 'HS256', typ: 'at+jwt' }
payload {
  role: 'customer',
  iss: 'https://api.bazarghar.example',
  aud: 'bazarghar-web',
  sub: '42',
  jti: 'demo-jti-0001',
  iat: 1793592000,
  exp: 1793592300
}
signature r2JG6sszWu6ouhqpOOTAdbT0pvQbH5V3p2JZYNO_MA8

এখানে exp − iat = 300, মানে ৫ মিনিট। Claim-গুলোর কথা যাচাইয়ের আগে বিশ্বাস করা যায় না। এবার node:crypto দিয়ে আসল HS256 নিজে বানান। এটি শেখার মডেল, production-এর জন্য নয়, তবু token-টি সত্যিকারের JWT.

// শেখার মডেল, production-এর জন্য নয়: হাতে লেখা আসল HS256 JWT
const { createHmac, timingSafeEqual } = require("node:crypto");
const b64u = (x) => Buffer.from(x).toString("base64url");
const text = (s) => Buffer.from(s, "base64url").toString();
const mac = (msg, key) => createHmac("sha256", key).update(msg).digest();

function sign(claims, key) {
  const head = b64u(JSON.stringify({ alg: "HS256", typ: "JWT" }));
  const body = b64u(JSON.stringify(claims));
  return `${head}.${body}.${b64u(mac(`${head}.${body}`, key))}`;
}

function verify(token, key) {
  const parts = token.split(".");
  if (parts.length !== 3) return "REJECT shape";
  const [head, body, sig] = parts;
  if (JSON.parse(text(head)).alg !== "HS256") return "REJECT alg";
  const want = mac(`${head}.${body}`, key);
  const got = Buffer.from(sig, "base64url");
  if (got.length !== want.length || !timingSafeEqual(got, want))
    return "REJECT signature";
  return "ACCEPT " + text(body);
}

const key = "example-secret-lesson-only-0123456789";
const token = sign({ sub: "42", role: "customer", exp: 1793592300 }, key);
console.log(token);

const [h, b, s] = token.split(".");
console.log("no key needed:", text(h), text(b));
console.log("valid   :", verify(token, key));

const changed = b64u(text(b).replace("customer", "admin"));
console.log("tampered:", verify(`${h}.${changed}.${s}`, key));
console.log("bad key :", verify(token, "another-example-secret"));

৩ · Express 5-এ jose দিয়ে token বানানো আর যাচাই

হাতে লেখা কোডটি বোঝার জন্য ছিল। আসল অ্যাপে পরিচিত library নিন। আমরা jose ব্যবহার করব, যা Web Crypto-র ওপর চলে, তাই Node-এর বাইরে edge runtime-এও চলে। লেখার সময়ে version:

$ npm install express@5.3.0 jose@6.2.14 cookie-parser@1.4.7 zod
$ npm install @prisma/client@7.10.1 @prisma/adapter-pg@7.10.1 pg
$ npm install -D prisma@7.10.1 tsx typescript@~6.0
found 0 vulnerabilities        (সত্যিকারের run, Node 24)

Secret আসে environment variable থেকে (পর্ব ৭৮), কোডে নয়। HS256-এর key অন্তত ৩২ byte এলোমেলো হওয়া উচিত, মনে রাখার মতো password নয়।

import { randomUUID } from 'node:crypto';
import { SignJWT, jwtVerify } from 'jose';
import { config } from './config.js';

export function signAccess(user: { id: number; role: string }, familyId: string) {
  return new SignJWT({ role: user.role, fid: familyId })
    .setProtectedHeader({ alg: 'HS256', typ: 'at+jwt' })
    .setIssuer(config.issuer)
    .setAudience(config.audience)
    .setSubject(String(user.id))
    .setJti(randomUUID())
    .setIssuedAt()
    .setExpirationTime(config.accessTtl)   // '5m'
    .sign(config.secret);                  // Uint8Array
}

export function verifyAccess(token: string) {
  return jwtVerify(token, config.secret, {
    algorithms: ['HS256'],                 // pinning
    issuer: config.issuer,
    audience: config.audience,
    typ: 'at+jwt',
    requiredClaims: ['sub', 'jti', 'exp'],
    clockTolerance: 5,                     // সেকেন্ড
  });
}

typ: 'at+jwt' ধারণাটি RFC 9068 থেকে নেওয়া। এতে অন্য কাজের জন্য বানানো JWT, যেমন email যাচাইয়ের token, ভুল করে access token হিসেবে চলে না। এবার পর্ব ২৬-এর middleware. Express 5-এ async middleware-এর rejected promise নিজেই error handler-এ যায়, তবে এখানে আমরা ইচ্ছা করে ধরছি, যাতে উত্তর হয় পরিষ্কার 401.

async function requireAuth(req: Request, res: Response, next: NextFunction) {
  const [scheme, token] = (req.headers.authorization ?? '').split(' ');
  res.set('WWW-Authenticate', 'Bearer');
  if (scheme !== 'Bearer' || !token) return problem(res, 401, 'missing_token');
  try {
    const { payload } = await verifyAccess(token);
    if (config.denylist && denied.has(payload.jti!)) return problem(res, 401, 'token_revoked');
    res.removeHeader('WWW-Authenticate');
    res.locals.auth = payload;
    next();
  } catch (e) {
    console.log(`auth.verify failed path=${req.path} code=${(e as { code?: string }).code}`);
    return problem(res, 401, 'invalid_token');
  }
}

ব্যবহারকারীকে শুধু invalid_token বলা হয়, ভেতরের কারণ যায় log-এ। Token কখনো log-এ নয়। problem হলো পর্ব ৩৩-এর problem details-এর ছোট রূপ।

নিজের verifier-এর পরীক্ষা

ভালো token গৃহীত হওয়া যথেষ্ট প্রমাণ নয়। খারাপ token বাতিল হচ্ছে কি না, সেটিই আসল পরীক্ষা। ল্যাবের ফাইলে নিজের key-তে কিছু ভুল token বানিয়ে নিজের verifier-এ দিয়েছি। ঘড়ি currentDate দিয়ে স্থির।

$ npx tsx src/verify-cases.ts     # সত্যিকারের run, jose 6.2.14
valid                  ACCEPT sub=42
payload changed        REJECT ERR_JWS_SIGNATURE_VERIFICATION_FAILED
other secret           REJECT ERR_JWS_SIGNATURE_VERIFICATION_FAILED
wrong aud              REJECT ERR_JWT_CLAIM_VALIDATION_FAILED aud
wrong iss              REJECT ERR_JWT_CLAIM_VALIDATION_FAILED iss
wrong typ              REJECT ERR_JWT_CLAIM_VALIDATION_FAILED typ
HS512 not pinned       REJECT ERR_JOSE_ALG_NOT_ALLOWED
alg none               REJECT ERR_JOSE_ALG_NOT_ALLOWED
exp + 3s (in leeway)   ACCEPT sub=42
exp + 6s (past)        REJECT ERR_JWT_EXPIRED exp

প্রতিটি লাইন একটি নিয়মের প্রমাণ। এই তালিকা unit test হিসেবে রাখুন। Library বা তার version বদলালে এই test-ই আগে বলে দেবে কোনো নিয়ম ঢিলে হলো কি না।

Clock skew আর ছাড়

Auth server আর API server-এর ঘড়ি হুবহু এক নয়। এই সামান্য পার্থক্যকে বলে clock skew. তাই clockTolerance দিয়ে কয়েক সেকেন্ড ছাড় রাখা হয়। ওপরের দুই লাইনেই তা দেখা গেছে: মেয়াদের ৩ সেকেন্ড পরে গৃহীত, ৬ সেকেন্ড পরে বাতিল। নিচের ব্লকে jose-এর সোর্সের একই শর্ত, সিমুলেটেড ঘড়িতে। Token তৈরি হয়েছে 1000 সময়ে, মেয়াদ 300 সেকেন্ড।

// সিমুলেটেড ঘড়ি: jose-এর নিয়মেই exp আর nbf দেখা
function timeCheck(c, now, leeway) {
  if (c.nbf !== undefined && c.nbf > now + leeway) return "too early";
  if (c.exp <= now - leeway) return "expired";
  return "ok";
}

const issued = 1000;                  // token তৈরির সময় (auth server-এর ঘড়ি)
const claims = { nbf: issued, exp: issued + 300 };

console.log("api-clock  leeway=0   leeway=5");
for (const now of [994, 996, 1000, 1299, 1300, 1304, 1305]) {
  const a = timeCheck(claims, now, 0).padEnd(10);
  console.log(String(now).padEnd(10), a, timeCheck(claims, now, 5));
}

jsonwebtoken বিকল্প: Node-এ এটি বহুদিনের জনপ্রিয় library, লেখার সময়ে 9.0.3. ল্যাবে একই নিয়মে চালিয়ে দেখেছি। নিয়ম একই: jwt.verify(t, secret, { algorithms: ['HS256'], issuer, audience, clockTolerance: 5 }). দুই library-র মধ্যে পার্থক্য হলো jose শুধু ESM আর Web Crypto-র ওপর চলে, তাই edge runtime-এ সুবিধা। পুরোনো CommonJS প্রকল্পে jsonwebtoken সহজ হতে পারে।

৪ · Algorithm pinning, পুরোনো ভুল আর key বদল

Token-এর header আসে ব্যবহারকারীর হাত ঘুরে। তাই “এটি কোন algorithm-এ যাচাই করব” প্রশ্নের উত্তর header থেকে নেওয়া যায় না। কোডে স্থির তালিকা দেওয়াকে বলে algorithm pinning. ওপরের algorithms: ['HS256'] সেই কাজই করে।

২০১৫ সালে প্রকাশিত নিরাপত্তা-গবেষণায় কিছু JWT library-র দুটি গোড়ার ভুল সামনে আসে। একটি alg: none: স্বাক্ষরহীন token-কে বৈধ ধরা। অন্যটি algorithm confusion: RS256-এর public key-কে HMAC-এর গোপন key ভাবা। বিস্তারিত ব্যাখ্যা সাইবার নিরাপত্তা কোর্সে আছে। Developer হিসেবে আপনার কাজ তিনটি:

• প্রতিটি verify call-এ algorithm তালিকা দেওয়া, যদিও library-র default ভালো মনে হয়।
• একই verify পথে কখনো HMAC আর public-key algorithm না মেশানো। RFC 8725 (২০২০) বলে, প্রতিটি key একটিই algorithm-এর জন্য।
• ওপরের মতো regression test রাখা, যাতে none আর ভুল alg বাতিল হওয়ার প্রমাণ থাকে।

ল্যাবে একটি Ed25519 verifier-কে HS256 token দিয়েছি। ফল HS token to Ed25519 verifier: ERR_JOSE_ALG_NOT_ALLOWED. Key দিয়ে কিছু হিসাব করার আগেই তালিকায় আটকে গেছে।

HS256, নাকি public-key স্বাক্ষর?

ল্যাবের একটি মাপ: একই ধরনের claim-এ Ed25519-এর signature অংশ ৮৬ অক্ষর, HS256-এর ৪৩ অক্ষর। RFC 9864 (২০২৫) সাধারণ EdDSA নামের বদলে নির্দিষ্ট Ed25519 নাম এনেছে, আর jose 6.2.14 দুটোই চেনে। আপনার অন্য service-এর library কোনটি চেনে, আগে দেখে নিন।

Key বদল: kid আর JWKS

Key চিরকাল রাখা যায় না। ফাঁসের সন্দেহ হলে বা নিয়মিত সময় পরে বদলাতে হয়। Public-key নকশায় issuer একটি URL-এ JWKS, মানে public key-র তালিকা, প্রকাশ করে। Token-এর header-এর kid বলে দেয় তালিকার কোন key লাগবে। মনে রাখবেন, kid শুধু জানা তালিকা থেকে বাছাই করে। সে নিজে কোনো key আনে না। নিচে সত্যিকারের run, Node-এর একটি ছোট server আর createRemoteJWKSet দিয়ে:

$ npx tsx src/jwks-demo.ts      # সত্যিকারের run, jose 6.2.14
old key                        ACCEPT kid=2026-10 jwks-fetches=1
old key again (cached)         ACCEPT kid=2026-10 jwks-fetches=1
new kid, cache miss            ACCEPT kid=2026-11 jwks-fetches=2
old token still valid          ACCEPT kid=2026-10 jwks-fetches=2
new after removal              ACCEPT kid=2026-11 jwks-fetches=2

ধাপের ক্রমটিই শিক্ষা। আগে নতুন key প্রকাশ, তারপর নতুন key-তে স্বাক্ষর, আর পুরোনো token-গুলোর মেয়াদ শেষ হলে তবেই পুরোনো key সরানো। অচেনা kid এলে verifier তালিকা একবার নতুন করে আনে, যা jwks-fetches=2 লাইনে দেখা যায়। ল্যাবে cooldownDuration: 0 ছিল শুধু demo-র জন্য। Production-এ default cooldown রাখুন, যাতে অচেনা kid-এর ঝড়ে JWKS endpoint-এ চাপ না পড়ে।

৫ · ছোট access token, লম্বা refresh token

মেয়াদ বড় হলে token চুরির ক্ষতি বড়। মেয়াদ ছোট হলে ব্যবহারকারীকে বারবার login করতে হয়। সমাধান হলো দুই token. Access token JWT, কয়েক মিনিট চলে, প্রতি API request-এ যায়। Refresh token এলোমেলো মান, মানে opaque token, কয়েক দিন চলে, যায় শুধু auth পথে। ল্যাবের মান: access ৫ মিনিট, refresh ১৪ দিন, আর একটি login-এর সর্বোচ্চ সীমা ৩০ দিন। এগুলো ঝুঁকি দেখে ঠিক করার মান, কোনো সার্বজনীন নিয়ম নয়।

হিসাব: ধরুন একসাথে সক্রিয় ব্যবহারকারী ২০,০০০ (ধরে নেওয়া মান)। প্রত্যেকে প্রতি ৩০০ সেকেন্ডে একবার refresh করলে সেকেন্ডে 20000 / 300 ≈ 66.7টি refresh. Access token ১৫ মিনিট হলে 20000 / 900 ≈ 22.2টি। মানে refresh-এর চাপ কমে, কিন্তু চুরির সময়সীমা তিনগুণ হয়। ল্যাবের access token ছিল ৩৬৯ অক্ষর, session ID ধরনের একটি cookie মান ৪৩ অক্ষর। JWT প্রতি request-এ বাড়তি ডেটা নিয়ে যায়, তাই claim ছোট রাখুন।

Database-এ দুটি table. Token family মানে একটি login, সাধারণত একটি device. পর্ব ৩৯-এর মতো Prisma schema:

model TokenFamily {
  id        String         @id @default(uuid())
  userId    Int
  user      User           @relation(fields: [userId], references: [id])
  createdAt DateTime       @default(now())
  expiresAt DateTime       // absolute সীমা
  revokedAt DateTime?
  tokens    RefreshToken[]

  @@index([userId])
}

model RefreshToken {
  id        Int         @id @default(autoincrement())
  tokenHash String      @unique // SHA-256, কাঁচা token নয়
  familyId  String
  family    TokenFamily @relation(fields: [familyId], references: [id])
  createdAt DateTime    @default(now())
  expiresAt DateTime
  usedAt    DateTime?

  @@index([familyId])
}

Refresh token ৩২ byte এলোমেলো, randomBytes(32) থেকে। Database-এ থাকে শুধু তার SHA-256. Database ফাঁস হলেও সেখান থেকে চালু token পাওয়া যায় না। Password-এর মতো ধীর hash এখানে লাগে না, কারণ মানটি নিজেই ২৫৬ bit এলোমেলো, অনুমান করার কিছু নেই। বাতিলের চিহ্ন family-তে একটি সারিতে থাকে, প্রতিটি token-এ নয়। ফলে “বাতিল” লেখার সময় একই মুহূর্তে একটি নতুন token তৈরি হলেও সেটি বেঁচে যায় না, কারণ প্রতিবার family দেখা হয়।

নিচের ধাপগুলোতে পুরো পথ দেখুন। Cookie-র মান Fxmn-q… ছোট করে দেখানো, hash-গুলো একই run-এর log থেকে নেওয়া। শুধু ৫ নম্বর ধাপের log লাইনটি browser run-এর।

{ "email": "rahima@example.com",
  "password": "example-password" }
scrypt hash মিলল

auth.login user=1 family=b4c11bbe
  token=a8bdfac8
database-এ a8bdfac8… (hash), কাঁচা token নয়

Set-Cookie: __Secure-rt=Fxmn-q…;
  Max-Age=1209600; Path=/api/auth;
  HttpOnly; Secure; SameSite=Strict
{ "accessToken": "eyJhbGciOiJIUzI1NiIs…",
  "user": { "id": 1, "name": "রহিমা" } }

Authorization: Bearer eyJhbGci…
jose: স্বাক্ষর, iss, aud, typ, exp ঠিক
200 {"sub":"1","role":"customer"}

auth.verify failed path=/me
  code=ERR_JWT_EXPIRED
401 {"title":"invalid_token","status":401}

auth.refresh ok family=b4c11bbe
  used=a8bdfac8 new=0583be17
Set-Cookie: __Secure-rt=(নতুন মান); …
{ "accessToken": "eyJhbGciOiJIUzI1NiIs…" }

Authorization: Bearer (নতুন token)
200 {"sub":"1","role":"customer"}
ব্যবহারকারী কিছুই টের পাননি

৬ · Refresh rotation আর reuse detection

Refresh token rotation-এ প্রতিটি refresh token একবারই চলে। ব্যবহৃত token আবার এলে কিছু গোলমাল আছে, যদিও server জানে না কে আসল। তখন reuse detection পুরো family বন্ধ করে। RFC 9700 (২০২৫) বলে, public client-এর refresh token হয় sender-constrained হবে, নয় rotation ব্যবহার করবে। কেন এই নিয়ম, তা সাইবার নিরাপত্তা কোর্সে আছে। এখানে দেখুন Prisma-তে এর কেন্দ্রের অংশ, log-এর লাইন বাদ দিয়ে:

export async function rotate(raw: string) {
  const row = await prisma.refreshToken.findUnique({
    where: { tokenHash: sha256(raw) },
    include: { family: { include: { user: true } } },
  });
  if (!row) throw new RefreshError('unknown');
  const { family } = row;
  if (family.revokedAt) throw new RefreshError('revoked');
  if (row.expiresAt < new Date() || family.expiresAt < new Date()) {
    throw new RefreshError('expired');
  }
  const next = newToken(family.id);
  const claimed = await prisma.$transaction(async (tx) => {
    const c = await tx.refreshToken.updateMany({   // atomic claim
      where: { id: row.id, usedAt: null },
      data: { usedAt: new Date() },
    });
    if (c.count === 1) await tx.refreshToken.create({ data: next.data });
    return c.count === 1;
  });
  if (!claimed) {
    await prisma.tokenFamily.update({
      where: { id: family.id }, data: { revokedAt: new Date() },
    });
    throw new RefreshError('reuse');
  }
  return { refresh: next.raw, access: await signAccess(family.user, family.id) };
}

মূল লাইনটি updateMany. usedAt খালি কি না দেখে আলাদা করে লিখলে দুটি request একসাথে “খালি” দেখত। এটি পর্ব ৪৩-এর race condition. শর্তসহ একটি UPDATE হলো atomic claim: database নিজে দুজনের মধ্যে একজনকেই জেতায়, তাই count হয় 1 বা 0. Transaction নিশ্চিত করে, দাবি আর নতুন token একসঙ্গে হয়, মাঝপথে crash হলে দুটোর কোনোটিই থাকে না।

Refresh আর logout route cookie ধরে চলে, তাই সেগুলো CSRF-এর আওতায় পড়ে। ল্যাবে দুটি স্তর আছে: SameSite=Strict আর Origin header-এর allowlist. Terminal থেকে অচেনা Origin পাঠালে উত্তর এসেছে 403 bad_origin. পুরো তালিকা পর্ব ৫০-এ।

এবার পুরো ঘটনা, আসল PostgreSQL-এ। একটি ড্রাইভার ফাইল login করে, দুবার refresh করে, তারপর সবচেয়ে পুরোনো cookie আবার পাঠায়।

$ npx tsx src/flow.ts      # সত্যিকারের run: Express 5.3.0, Prisma 7.10.1, embedded PostgreSQL
LOGIN 200
…
GET /me 200 {"sub":"1","role":"customer"}
GET /me no token 401 Bearer {"title":"missing_token","status":401}
REFRESH 1 200 cookie changed: true
REFRESH 2 200 cookie changed: true
REFRESH bad Origin 403 {"title":"bad_origin","status":403}
REUSE old token 401 {"title":"refresh_failed","status":401}
NEWEST token after family kill 401 {"title":"refresh_failed","status":401}
old access still works? 200

# API log
auth.login user=1 family=b4c11bbe token=a8bdfac8
auth.refresh ok family=b4c11bbe used=a8bdfac8 new=0583be17
auth.refresh ok family=b4c11bbe used=0583be17 new=8ac02d92
auth.reuse ALERT user=1 family=b4c11bbe token=a8bdfac8 action=family-revoked
auth.refresh denied family=b4c11bbe token=8ac02d92 reason=family-revoked

# database-এর অবস্থা
family b4c11bbe revokedAt=set
  id=1 hash=a8bdfac8… hashLen=64 usedAt=set
  id=2 hash=0583be17… hashLen=64 usedAt=set
  id=3 hash=8ac02d92… hashLen=64 usedAt=null

hashLen=64 মানে SHA-256-এর ৬৪ hex অক্ষর। শেষ লাইনটি খেয়াল করুন: old access still works? 200. Family বন্ধ হলেও হাতে থাকা access token মেয়াদ পর্যন্ত চলে। অংশ ৮-এ এটিই আসল সমস্যা। নিচের ধাপগুলো একই run-এর মান দিয়ে সাজানো।

1row = findUnique(sha256(raw))2if family.revokedAt: 4013c = updateMany(usedAt: null)4if c.count == 0:5  family.revokedAt = now; alert6create(next token)7return new access, new cookie

একই যুক্তি ছোট মডেলে চালিয়ে দেখুন। এখানে Map হলো table, আর এতে শুধু hash জমা থাকে।

// শেখার মডেল: Map = refresh token-এর table, শুধু hash জমা থাকে
const { createHash } = require("node:crypto");
const sha = (s) => createHash("sha256").update(s).digest("hex");

const rows = new Map();          // hash -> { family, used }
const revoked = new Set();       // বাতিল family
let n = 0;

function issue(family) {
  // বাস্তবে randomBytes(32); এখানে একই আউটপুটের জন্য সিমুলেটেড
  const raw = "rt" + ++n + "-example";
  rows.set(sha(raw), { family, used: false });
  return raw;
}

function refresh(raw) {
  const row = rows.get(sha(raw));
  if (!row) return "401 unknown";
  if (revoked.has(row.family)) return "401 family revoked";
  if (row.used) {
    revoked.add(row.family);
    return "401 REUSE, family killed: " + row.family;
  }
  row.used = true;
  return "200 next=" + issue(row.family);
}

const a = issue("phone");
const lap = issue("laptop");
console.log("1", refresh(a));         // rt3
console.log("2", refresh("rt3-example"));   // rt4
console.log("3", refresh(a));         // পুরোনো copy আবার
console.log("4", refresh("rt4-example"));   // সবচেয়ে নতুনটিও বন্ধ
console.log("5", refresh(lap));       // অন্য family অক্ষত
console.log("stored:", [...rows.keys()][0].slice(0, 12), "raw stored?", rows.has(a));

৭ · Browser-এ token কোথায় রাখবেন

এখানে সম্পূর্ণ নিরাপদ জায়গা বলে কিছু নেই, শুধু ভিন্ন ঝুঁকি। সাধারণ শর্ত হলো XSS: পাতায় অন্যের script চললে কী হয়?

সৎ কথাটি এই: HttpOnly XSS থামায় না। Script fetch('/api/auth/refresh') ডাকলে cookie নিজে যায়, আর উত্তরের access token সে পড়তে পারে। লাভ হলো সে refresh token নিজে হাতে পায় না, তাই ক্ষতি সেই পাতা খোলা থাকার সময়ে সীমিত। XSS-এর আসল প্রতিরোধ XSS আর CSP. localStorage দলের যুক্তিও বাতিল নয়: ছোট অ্যাপ, খুব কড়া CSP আর কম ঝুঁকিতে কেউ কেউ এটি বেছে নেন। শুধু দামটি জেনে নিন।

ল্যাবের cookie: __Secure-rt=…; Path=/api/auth; HttpOnly; Secure; SameSite=Strict. Path ছোট, তাই সাধারণ API request-এ cookie যায় না। পাতা আর API একই site-এ থাকলে এটি সহজ। আলাদা site হলে SameSite=None, credentials: 'include' আর CORS-এর credential নিয়ম লাগে, যা পর্ব ২৬-এ আছে। আমরা Vite proxy দিয়ে /api-কে একই origin রেখেছি। Edge-এ চালিয়ে দেখা ফল:

# সত্যিকারের run, Edge headless, Playwright দিয়ে চালানো
document.cookie = ''   localStorage.length = 0
cookie __Secure-rt  httpOnly True  secure True  sameSite Strict  path /api/auth  valueLen 43

৮ · Logout কেন কঠিন: revocation আর denylist

Session-এ সারি মুছলেই শেষ। JWT যাচাই শুধু স্বাক্ষর আর সময় দেখে, তাই “এটি বাতিল” বলার জায়গা নেই। একে বলে revocation-এর সমস্যা। ল্যাবে logout করে একই access token আবার পাঠিয়েছি। প্রথমবার denylist বন্ধ, দ্বিতীয়বার চালু।

$ npx tsx src/logout-flow.ts     # সত্যিকারের run, DENYLIST=off
before logout 200
logout 204
after logout, access 200
after logout, refresh 401

$ npx tsx src/logout-flow.ts     # সত্যিকারের run, DENYLIST=on
before logout 200
logout 204
after logout, access 401
after logout, refresh 401

Denylist বন্ধ থাকলে logout-এর পরেও token চলেছে, আর refresh বন্ধ। তাই সবচেয়ে খারাপ ক্ষেত্রে logout-এর সততা access token-এর মেয়াদের সমান, এখানে ৫ মিনিট। দুটি পথ আছে:

• মেনে নেওয়া: বেশিরভাগ অ্যাপে ৫ মিনিট গ্রহণযোগ্য, যদি refresh বন্ধ থাকে।
• Denylist: বাতিল jti একটি store-এ রাখা, প্রতি request-এ দেখা। ল্যাবে এটি একটি Map, যা একটি process-এই সীমিত। একাধিক server-এ পর্ব ৪৪-এর Redis লাগবে, আর TTL হবে token-এর বাকি মেয়াদ।

Denylist-এর আকার ছোট, এটি সুখবর। সারি থাকে শুধু মেয়াদ শেষ পর্যন্ত। সেকেন্ডে ২টি logout (ধরে নেওয়া মান) আর ৩০০ সেকেন্ড মেয়াদে সর্বোচ্চ 2 × 300 = 600টি সারি। দাম আকারে নয়, নির্ভরতায়: প্রতি request-এ একটি lookup আবার ফিরে এল, যা না করাই ছিল JWT-র মূল লাভ। “সব device থেকে বের করা” বা role বদলের জন্য family বন্ধ করা যায়, আর জরুরি হলে key বদলে সবার token একসঙ্গে বাতিল করা যায়। পরেরটিতে সবাইকে আবার login করতে হয়।

৯ · React-এ সংযোগ: memory, fetch wrapper আর single-flight

Access token থাকবে একটি module-এর ভেতরের সাধারণ variable-এ, React state-এ নয়। এতে তা কোনো component tree বা devtools state-এ ছড়ায় না। পুরো auth কথাবার্তা এক জায়গায়, একটি fetch wrapper-এ। নিচের কোড ল্যাবের, শুধু demo-র জন্য রাখা একটি mode সুইচ বাদ দিয়ে দেখানো।

let accessToken: string | null = null;
let refreshing: Promise<string | null> | null = null;
let onSessionLost = () => {};

export const setAccessToken = (t: string | null) => { accessToken = t; };
export const setOnSessionLost = (fn: () => void) => { onSessionLost = fn; };

async function doRefresh(): Promise<string | null> {
  const res = await fetch('/api/auth/refresh', { method: 'POST' });
  if (!res.ok) { accessToken = null; return null; }
  accessToken = (await res.json()).accessToken as string;
  return accessToken;
}

export function refreshOnce(): Promise<string | null> {
  refreshing ??= doRefresh().finally(() => { refreshing = null; });
  return refreshing;
}

export async function api(path: string, init: RequestInit = {}) {
  const send = (token: string | null) => {
    const headers = new Headers(init.headers);
    if (token) headers.set('Authorization', `Bearer ${token}`);
    return fetch(path, { ...init, headers });
  };

  const sent = accessToken;
  const res = await send(sent);
  if (res.status !== 401) return res;

  // অন্য কেউ এর মধ্যে নতুন token এনে থাকলে refresh লাগবে না
  const fresh = accessToken && accessToken !== sent ? accessToken : await refreshOnce();
  if (!fresh) { onSessionLost(); return res; }
  return send(fresh);                 // retry শুধু একবার
}

কেন্দ্রের লাইন refreshing ??= …. চলমান refresh থাকলে নতুন refresh শুরু হয় না, সবাই একই Promise-এর জন্য অপেক্ষা করে। এটিই single-flight, যা আপনি পর্ব ৪৪-এর cache stampede-এ দেখেছেন। sent আর fresh-এর লাইন একটি দেরিতে আসা 401 সামলায়: সেই request পুরোনো token-এ গিয়েছিল, কিন্তু এর মধ্যে নতুন token চলে এসেছে। 401-এর পরে POST-ও আবার পাঠানো নিরাপদ, কারণ যাচাইয়ে আটকে যাওয়া request কোনো কাজ করেনি।

1const res = await send(sent)2if (res.status !== 401) return res3refreshing ??= doRefresh()4.finally(() => refreshing = null)5return send(fresh)

Single-flight না থাকলে কী হয়? নিচের মডেলে একই server, দুইভাবে।

// শেখার মডেল: একটি server, তিনটি একসাথে চলা request, মেয়াদ শেষ token
const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function scenario(useSingleFlight) {
  let cookie = "rt0", valid = "rt0", family = "alive";
  let calls = 0, inFlight = null;

  async function serverRefresh(sent) {
    calls++;
    await sleep(10);
    if (family === "dead" || sent !== valid) { family = "dead"; return null; }
    valid = "rt" + calls;
    cookie = valid;
    return "new-access-" + calls;
  }
  const refreshOnce = () =>
    (inFlight ??= serverRefresh(cookie).finally(() => { inFlight = null; }));

  async function api() {
    await sleep(2);                         // প্রথম চেষ্টা: 401
    const t = await (useSingleFlight ? refreshOnce() : serverRefresh(cookie));
    return t ? 200 : 401;                   // নতুন token পেলে retry সফল
  }

  const out = await Promise.all([api(), api(), api()]);
  console.log(useSingleFlight ? "single-flight:" : "naive        :",
    "refresh calls =", calls, "| results =", out.join(" "), "| family =", family);
}

scenario(false).then(() => scenario(true));

ল্যাবে React 19.3.1 আর Vite 8.3.5, API-তে শুধু demo-র জন্য ACCESS_TTL=3s. ৫ সেকেন্ড ছাড় মিলিয়ে token প্রায় ৮ সেকেন্ড চলে, তাই Playwright ৯ সেকেন্ড অপেক্ষা করে click করেছে।

# সত্যিকারের run, Edge headless, একটি local run-এর সময়
=== single-flight ===
    32 ms GET  /api/me              401
    32 ms GET  /api/orders          401
    32 ms GET  /api/cart            401
    47 ms POST /api/auth/refresh    200
    50 ms GET  /api/me              200
    52 ms GET  /api/cart            200
    52 ms GET  /api/orders          200
status: logged-in 1

=== naive (single-flight ছাড়া) ===
    21 ms GET  /api/me              401
    22 ms GET  /api/orders          401
    23 ms GET  /api/cart            401
    31 ms POST /api/auth/refresh    200
    36 ms GET  /api/me              200
    53 ms POST /api/auth/refresh    401
    53 ms POST /api/auth/refresh    401
status: logged-out

# API log, naive
auth.refresh ok family=7eb83ce1 used=4cba9a11 new=4b66b0a7
auth.reuse ALERT user=1 family=7eb83ce1 token=4cba9a11 action=family-revoked
auth.reuse ALERT user=1 family=7eb83ce1 token=4cba9a11 action=family-revoked

কোনো চোর নেই, তবু নিরাপত্তা-সতর্কবার্তা, আর ব্যবহারকারী logout. তাই production-এ হঠাৎ reuse alert বেড়ে গেলে আগে নিজের client-এর কোড সন্দেহ করুন।

Reload, StrictMode আর একাধিক tab

Memory-র token reload-এ হারায়। তাই অ্যাপ খোলার সময় AuthProvider একটি silent refresh করে। পর্ব ১৭-এর Context আর পর্ব ১৩-এর cleanup-এর চেনা গড়ন:

useEffect(() => {
  setOnSessionLost(() => setUser(null));
  let alive = true;
  (async () => {
    if (await refreshOnce()) {          // reload-এর পরে নীরব refresh
      const res = await api('/api/me');
      if (alive && res.ok) setUser(await res.json());
    }
    if (alive) setReady(true);
  })();
  return () => { alive = false; };
}, []);

Development-এ StrictMode effect দুবার চালায়। Single-flight না থাকলে এই একটি reload-ই ব্যবহারকারীকে logout করে। আসল run-এর তুলনা:

# সত্যিকারের run, Vite dev, StrictMode চালু, reload
=== naive ===
    47 ms POST /api/auth/refresh    200
    49 ms GET  /api/me              200
    66 ms POST /api/auth/refresh    401
status: logged-out
=== single-flight ===
    46 ms POST /api/auth/refresh    200
    49 ms GET  /api/me              200
    50 ms GET  /api/me              200
status: logged-in 1

Single-flight একটি tab-এর ভেতরে কাজ করে, কারণ variable প্রতিটি tab-এর আলাদা। দুটি tab একসাথে refresh করলে কী হয়? একই cookie, তাই একই সমস্যা। ল্যাবে দুই tab প্রায় একসাথে click করে দুবার চালিয়েছি, দুবারই tab B বের হয়ে গেছে। সমাধান Web Locks API, যা একই origin-এর tab-দের মধ্যে একবারে একজনকে lock দেয়। HTTPS-এ (আর localhost-এ) চলে, ২০২২ সাল থেকে সব বড় browser-এ আছে।

const refreshLocked = () =>
  navigator.locks.request('bazarghar-refresh', doRefresh);

export function refreshOnce() {
  refreshing ??= refreshLocked().finally(() => { refreshing = null; });
  return refreshing;
}

# সত্যিকারের run, Edge, দুই tab (A, B), লক ছাড়া
…
    19 ms A POST /api/auth/refresh    200
    24 ms B POST /api/auth/refresh    401
A: logged-in 1 | B: logged-out

# Web Locks সহ
…
    18 ms A POST /api/auth/refresh    200
    26 ms B POST /api/auth/refresh    200
…
A: logged-in 1 | B: logged-in 1

Lock থাকলে B অপেক্ষা করে, আর পাঠায় A-র রেখে যাওয়া নতুন cookie. তাই সেটি reuse নয়। পর্ব ১৯-এর TanStack Query ব্যবহার করলে তার queryFn-এ এই api()-ই ডাকুন। Logout-এর খবর অন্য tab-এ দ্রুত পৌঁছাতে BroadcastChannel কাজে লাগে।

১০ · সাধারণ ভুল আর AI-এর যুগে JWT কোড

AI খুব দ্রুত auth কোড লিখে দেয়, আর সেটি প্রায়ই চলে। সমস্যা হলো “চলে” আর “নিরাপদ” এক কথা নয়। নিচের ভুলগুলো মানুষের কোডেও দেখা যায়, AI-এর কোডেও।

AI-এর লেখা auth কোড হাতে পেলে

• Package আর option আসলেই আছে কি না npm view আর official docs-এ দেখেছি
• Verify-তে algorithm তালিকা, iss, aud আছে, আর decode কোথাও যাচাইয়ের কাজ করছে না
• নিজের key-তে বদলানো আর মেয়াদ শেষ token চালিয়ে বাতিল হতে দেখেছি
• Payload পড়ে দেখেছি, সেখানে গোপন কিছু নেই
• Browser-এর Network tab-এ দেখেছি, একসাথে অনেক 401-এ refresh একবারই হয়
• Diff পড়েছি: কোনো অপ্রয়োজনীয় dependency নেই, কোনো error চুপ করে লুকানো নেই
• AI-কে আসল secret, token বা production ডেটা দিইনি