JSON Web Token (JWT) ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ?

Question

IT Interview Practice · Accepted Answer

ਇੱਕ **JSON Web Token (JWT)** ਇੱਕ ਸੰਖੇਪ, URL-ਸੁਰੱਖਿਅਤ, ਸਵੈ-ਸੰਪੂਰਨ ਟੋਕਨ ਹੈ ਜੋ ਕਿਸੇ ਉਪਭੋਗਤਾ ਬਾਰੇ claims ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ। ਸਰਵਰ ਇਸ ਨੂੰ ਇੱਕ ਵਾਰ ਸਾਈਨ ਕਰਦਾ ਹੈ; ਬਾਅਦ ਵਿੱਚ ਇਹ ਹਰ ਬੇਨਤੀ ਉੱਤੇ ਡਾਟਾਬੇਸ ਵੇਖੇ ਬਿਨਾਂ ਟੋਕਨ ਦੀ **ਪੁਸ਼ਟੀ** ਕਰ ਸਕਦਾ ਹੈ — ਇਹੀ JWT-ਅਧਾਰਿਤ auth ਨੂੰ *stateless* ਬਣਾਉਂਦਾ ਹੈ।

## ਬਣਤਰ: ਤਿੰਨ base64url ਹਿੱਸੇ

ਇੱਕ JWT `header.payload.signature` ਹੁੰਦਾ ਹੈ, ਬਿੰਦੀਆਂ ਨਾਲ ਜੁੜੇ ਤਿੰਨ base64url-ਏਨਕੋਡਡ ਖੰਡ:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9   ← header
.eyJzdWIiOiIxMjMiLCJleHAiOjE3MDB9      ← payload (claims)
.dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1    ← signature
```

- **Header** — ਸਾਈਨ ਕਰਨ ਦਾ ਐਲਗੋਰਿਦਮ, ਜਿਵੇਂ `{ "alg": "HS256", "typ": "JWT" }`।
- **Payload** — **claims**: ਮਿਆਰੀ ਜਿਵੇਂ `sub` (ਵਿਸ਼ਾ/ਉਪਭੋਗਤਾ id), `exp` (ਮਿਆਦ ਖ਼ਤਮ), `iat` (ਜਾਰੀ ਹੋਣ ਦਾ ਸਮਾਂ), `iss` (ਜਾਰੀਕਰਤਾ), ਨਾਲ ਹੀ ਕੋਈ ਵੀ ਕਸਟਮ ਖੇਤਰ (`role`, `email`)।
- **Signature** — header ਅਤੇ payload ਉੱਤੇ ਇੱਕ secret ਜਾਂ private key ਨਾਲ ਗਿਣੀ ਜਾਂਦੀ ਹੈ।

> Payload **ਏਨਕੋਡ ਹੈ, ਏਨਕ੍ਰਿਪਟ ਨਹੀਂ**। ਕੋਈ ਵੀ ਇਸ ਨੂੰ base64-ਡੀਕੋਡ ਕਰ ਕੇ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਕਦੇ ਵੀ ਪਾਸਵਰਡ ਜਾਂ ਭੇਦ JWT ਵਿੱਚ ਨਾ ਪਾਓ।

## ਸਾਈਨਿੰਗ ਅਤੇ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ

```
signature = HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret
)
```

- **HS256** (ਸਮਮਿਤੀ): ਇੱਕੋ secret ਸਾਈਨ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ। ਸਾਦਾ, ਪਰ ਹਰ ਪੁਸ਼ਟੀਕਰਤਾ ਕੋਲ secret ਹੋਣਾ ਲਾਜ਼ਮੀ ਹੈ।
- **RS256** (ਅਸਮਮਿਤੀ): ਇੱਕ **private key** ਸਾਈਨ ਕਰਦੀ ਹੈ, ਇੱਕ **public key** ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ। auth ਸਰਵਰ private key ਰੱਖਦਾ ਹੈ; ਹੋਰ ਸੇਵਾਵਾਂ public key ਨਾਲ ਪੁਸ਼ਟੀ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਕਦੇ ਵੀ ਟੋਕਨ ਨਹੀਂ ਬਣਾ ਸਕਦੀਆਂ।

ਹਰ ਬੇਨਤੀ ਉੱਤੇ ਸਰਵਰ ਮਿਲੇ header+payload ਉੱਤੇ signature ਮੁੜ ਗਿਣਦਾ ਹੈ ਅਤੇ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਜੇ ਇਹ ਮਿਲਦੇ ਹਨ ਅਤੇ `exp` ਭਵਿੱਖ ਵਿੱਚ ਹੈ, ਤਾਂ ਟੋਕਨ ਉੱਤੇ ਭਰੋਸਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ — ਕਿਸੇ session store ਦੀ ਲੋੜ ਨਹੀਂ।

```js
const jwt = require("jsonwebtoken");

const token = jwt.sign({ sub: "123", role: "admin" }, SECRET, {
  expiresIn: "15m",
});

try {
  const claims = jwt.verify(token, SECRET); // ਜੇ ਛੇੜਛਾੜ ਹੋਈ ਜਾਂ ਮਿਆਦ ਖ਼ਤਮ ਹੋਈ ਤਾਂ ਗ਼ਲਤੀ ਸੁੱਟਦਾ ਹੈ
  // claims.sub === "123"
} catch (e) {
  // ਰੱਦ ਕਰੋ: ਅਵੈਧ ਜਾਂ ਮਿਆਦ ਖ਼ਤਮ
}
```

## ਔਖਾ ਹਿੱਸਾ: ਰੱਦ ਕਰਨਾ (revocation)

ਕਿਉਂਕਿ ਪੁਸ਼ਟੀ stateless ਹੈ, ਤੁਸੀਂ ਸਰਵਰ-ਪਾਸੇ ਸਿਰਫ਼ "ਮਿਟਾ ਕੇ" ਕਿਸੇ ਟੋਕਨ ਨੂੰ ਇਸ ਦੀ ਮਿਆਦ ਖ਼ਤਮ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ **ਅਵੈਧ ਨਹੀਂ ਕਰ** ਸਕਦੇ। ਆਮ ਉਪਾਅ:

- access token ਨੂੰ **ਥੋੜ੍ਹ-ਚਿਰੇ** (5–15 ਮਿੰਟ) ਰੱਖੋ ਅਤੇ ਇੱਕ ਲੰਬੇ-ਚਿਰੇ **refresh token** ਨਾਲ ਜੋੜੋ।
- ਲਾਗਆਊਟ/ਸਮਝੌਤੇ ਲਈ ਰੱਦ ਕੀਤੇ ਟੋਕਨ id (`jti`) ਦੀ ਇੱਕ ਛੋਟੀ **denylist** ਰੱਖੋ — ਇਹ ਥੋੜ੍ਹਾ state ਵਾਪਸ ਲਿਆਉਂਦਾ ਹੈ।
- ਸਾਈਨਿੰਗ ਕੁੰਜੀਆਂ ਨੂੰ ਘੁੰਮਾਓ (rotate)।

## ਸਟੋਰੇਜ ਸਮਝੌਤੇ

| ਸਟੋਰੇਜ | ਫ਼ਾਇਦਾ | ਨੁਕਸਾਨ |
|---|---|---|
| `httpOnly` ਕੁਕੀ | JS ਦੁਆਰਾ ਪੜ੍ਹੀ ਨਹੀਂ ਜਾ ਸਕਦੀ (XSS-ਸੁਰੱਖਿਅਤ) | CSRF ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ |
| `localStorage` | ਸਾਦਾ, CSRF ਨਹੀਂ | XSS ਲਈ ਖੁੱਲ੍ਹਾ |

## ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

JWT API, ਮਾਈਕ੍ਰੋਸਰਵਿਸਾਂ ਅਤੇ SPA ਵਿੱਚ stateless auth ਨੂੰ ਸ਼ਕਤੀ ਦਿੰਦੇ ਹਨ — ਇੱਕ ਸੇਵਾ ਸਿਰਫ਼ ਇੱਕ signature ਦੀ ਪੁਸ਼ਟੀ ਕਰ ਕੇ ਬੇਨਤੀ ਉੱਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੀ ਹੈ, ਬਿਨਾਂ ਕਿਸੇ ਸਾਂਝੇ session store ਦੇ। ਪਰ ਇਹੀ statelessness ਕਲਾਸਿਕ ਇੰਟਰਵਿਊ ਫੰਦਾ ਹੈ: ਟੋਕਨਾਂ ਨੂੰ ਸੌਖਿਆਂ ਰੱਦ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, payload ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ `alg` ਦੀ ਗੜਬੜ ਜਾਂ ਮਿਆਦ ਦੀ ਜਾਂਚ ਦਾ ਗਾਇਬ ਹੋਣਾ ਅਸਲੀ ਕਮਜ਼ੋਰੀਆਂ ਹਨ। signature ਕੀ ਸੁਰੱਖਿਅਤ ਕਰਦੀ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ, ਇਹ ਠੀਕ-ਠੀਕ ਜਾਣਨਾ JWT ਨੂੰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਵਰਤਣ ਲਈ ਜ਼ਰੂਰੀ ਹੈ।

ਸਟੋਰੇਜ	ਫ਼ਾਇਦਾ	ਨੁਕਸਾਨ
`httpOnly` ਕੁਕੀ	JS ਦੁਆਰਾ ਪੜ੍ਹੀ ਨਹੀਂ ਜਾ ਸਕਦੀ (XSS-ਸੁਰੱਖਿਅਤ)	CSRF ਸੁਰੱਖਿਆ ਦੀ ਲੋੜ
`localStorage`	ਸਾਦਾ, CSRF ਨਹੀਂ	XSS ਲਈ ਖੁੱਲ੍ਹਾ

ਬਣਤਰ: ਤਿੰਨ base64url ਹਿੱਸੇ

ਸਾਈਨਿੰਗ ਅਤੇ ਪੁਸ਼ਟੀ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ

ਔਖਾ ਹਿੱਸਾ: ਰੱਦ ਕਰਨਾ (revocation)

ਸਟੋਰੇਜ ਸਮਝੌਤੇ

ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ

ਸੰਬੰਧਿਤ ਸਵਾਲ