ਤੁਹਾਨੂੰ access token ਅਤੇ refresh token ਦੋਵਾਂ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ?

Question

IT Interview Practice · Accepted Answer

ਦੋ token ਇੱਕ ਸਿੱਧੇ ਟਕਰਾਅ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਹੁੰਦੇ ਹਨ: ਇੱਕ access token ਨੂੰ **ਹਰ request 'ਤੇ ਭੇਜਣਾ** ਪੈਂਦਾ ਹੈ (ਇਸ ਲਈ ਇਹ ਬਹੁਤ ਜ਼ਿਆਦਾ ਉਜਾਗਰ ਹੁੰਦਾ ਹੈ), ਫਿਰ ਵੀ ਤੁਸੀਂ ਅਜਿਹੀਆਂ session ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਵਾਰ-ਵਾਰ login ਕਰਵਾਏ ਬਿਨਾਂ **ਲੰਬਾ ਸਮਾਂ ਟਿਕਣ**। ਤੁਸੀਂ ਇੱਕੋ token ਵਿੱਚ ਦੋਵੇਂ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਨਹੀਂ ਰੱਖ ਸਕਦੇ — ਇਸ ਲਈ ਤੁਸੀਂ ਕੰਮ ਵੰਡ ਲੈਂਦੇ ਹੋ।

## ਦੋ ਭੂਮਿਕਾਵਾਂ

- **Access token** — ਥੋੜ੍ਹ-ਚਿਰਾ (ਆਮ ਤੌਰ 'ਤੇ 5–15 ਮਿੰਟ), ਹਰ API ਕਾਲ 'ਤੇ `Authorization` header ਵਿੱਚ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਕਿਉਂਕਿ ਇਹ ਲਗਾਤਾਰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਲੀਕ ਦੀ ਸੰਭਾਵਨਾ ਵੱਧ ਹੈ; ਇਸ ਨੂੰ ਥੋੜ੍ਹ-ਚਿਰਾ ਰੱਖਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਚੋਰੀ ਹੋਇਆ token ਲਗਭਗ ਤੁਰੰਤ ਹੀ ਹੱਦ ਪਾਰ ਕਰ ਜਾਂਦਾ ਹੈ।
- **Refresh token** — ਲੰਬ-ਚਿਰਾ (ਦਿਨ/ਹਫ਼ਤੇ), **ਸਿਰਫ਼** auth server ਦੇ token endpoint ਨੂੰ ਨਵੇਂ access token ਲੈਣ ਲਈ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਘੱਟ ਹੀ ਸਫ਼ਰ ਕਰਦਾ ਹੈ, ਵਧੇਰੇ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ server-side revoke ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

```
Login ──▶ access (15m) + refresh (30d)
ਹਰ API ਕਾਲ ──▶ access ਭੇਜੋ
Access ਦੀ ਹੱਦ ਲੰਘੀ ──▶ refresh ਭੇਜੋ ──▶ ਨਵਾਂ access (+ rotate ਕੀਤਾ refresh)
```

## ਸਿਰਫ਼ ਇੱਕ token ਕਿਉਂ ਨਹੀਂ?

| | ਇੱਕ ਲੰਬ-ਚਿਰਾ access token | Access + refresh |
|---|---|---|
| ਉਜਾਗਰੀ | ਹਰ request 'ਤੇ ਭੇਜਿਆ, ਲੰਬਾ ਜੀਵੇ → ਵੱਡੀ ਚੋਰੀ ਦੀ ਵਿੰਡੋ | Access ਥੋੜ੍ਹ-ਚਿਰਾ; refresh ਘੱਟ ਭੇਜਿਆ |
| Revocation | ਔਖਾ (stateless JWT un-issue ਨਹੀਂ ਹੋ ਸਕਦਾ) | Refresh token revoke ਕਰੋ; access ਮਿੰਟਾਂ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ |
| UX | ਥੋੜ੍ਹ-ਚਿਰਾ ਹੋਵੇ ਤਾਂ ਵਾਰ-ਵਾਰ re-login | ਬਿਨਾਂ credential ਮੁੜ ਦਾਖ਼ਲ ਕੀਤੇ logged in ਰਹਿੰਦਾ ਹੈ |
| ਲੀਕ ਦਾ ਵਿਸਫੋਟ ਦਾਇਰਾ | ਵੱਡਾ | ਛੋਟਾ (access ਜਲਦੀ ਹੱਦ ਪਾਰ ਕਰਦਾ ਹੈ) |

- **ਇੱਕ ਥੋੜ੍ਹ-ਚਿਰਾ access token, ਕੋਈ refresh ਨਹੀਂ** → ਸੁਰੱਖਿਅਤ, ਪਰ ਯੂਜ਼ਰ ਹਰ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ logout ਹੋ ਜਾਂਦਾ ਹੈ। ਬਹੁਤ ਖ਼ਰਾਬ UX।
- **ਇੱਕ ਲੰਬਾ access token** → ਵਧੀਆ UX, ਪਰ ਲੀਕ ਹੋਇਆ token ਲੰਬੇ ਸਮੇਂ ਲਈ ਵੈਧ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸੌਖਿਆਂ revoke ਨਹੀਂ ਹੁੰਦਾ।
- **Access + refresh** → ਛੋਟੀ ਉਜਾਗਰੀ ਵਿੰਡੋ *ਅਤੇ* ਲੰਬੀਆਂ session। Refresh token ਇਕਲੌਤਾ ਲੰਬ-ਚਿਰਾ ਰਾਜ਼ ਹੈ, ਅਤੇ ਇਹ ਇੱਕ ਸੁਰੱਖਿਅਤ ਥਾਂ 'ਤੇ ਰਹਿੰਦਾ ਹੈ।

## ਇਹ ਵੰਡ ਕੀ ਸੰਭਵ ਕਰਦੀ ਹੈ

- **Stateless access token ਦੇ ਬਾਵਜੂਦ revocation।** ਤੁਸੀਂ ਕਿਸੇ JWT access token ਨੂੰ ਇਸ ਦੀ ਹੱਦ ਲੰਘਣ ਤੋਂ ਪਹਿਲਾਂ ਅਵੈਧ ਨਹੀਂ ਕਰ ਸਕਦੇ, ਪਰ ਤੁਸੀਂ refresh token ਨੂੰ ਹਟਾ/ਇਨਕਾਰ ਕਰ *ਸਕਦੇ ਹੋ*, ਇਸ ਲਈ session ਅਗਲੇ refresh 'ਤੇ (ਮਿੰਟਾਂ ਦੇ ਅੰਦਰ) ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ।
- **Refresh token rotation** — ਹਰ ਵਰਤੋਂ 'ਤੇ ਇੱਕ ਨਵਾਂ refresh token ਜਾਰੀ ਕਰੋ ਅਤੇ ਪੁਰਾਣੇ ਦੀ ਮੁੜ-ਵਰਤੋਂ (ਚੋਰੀ ਦਾ ਸੰਕੇਤ) ਦਾ ਪਤਾ ਲਗਾਓ, ਫਿਰ ਪੂਰੀ chain revoke ਕਰੋ।
- **ਘੱਟੋ-ਘੱਟ ਉਜਾਗਰੀ** — ਲੰਬ-ਚਿਰਾ ਰਾਜ਼ (refresh) ਬਿਲਕੁਲ ਇੱਕ endpoint ਨੂੰ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਆਦਰਸ਼ ਤੌਰ 'ਤੇ ਇੱਕ `httpOnly` cookie ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ, XSS ਦੀ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ।

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

ਇਹ ਮਿਆਰੀ ਆਧੁਨਿਕ auth ਡਿਜ਼ਾਈਨ ਹੈ, ਅਤੇ interviewer ਇਹ ਪੁੱਛਦੇ ਹਨ ਤਾਂ ਜੋ ਦੇਖ ਸਕਣ ਕਿ ਕੀ ਤੁਸੀਂ *ਕਿਉਂ* ਸਮਝਦੇ ਹੋ, ਸਿਰਫ਼ *ਕਿਵੇਂ* ਨਹੀਂ। ਮੁੱਖ ਸੂਝ trade-off ਹੈ: statelessness ਅਤੇ ਛੋਟੀ ਉਜਾਗਰੀ (access) ਬਨਾਮ ਲੰਬੀਆਂ session ਅਤੇ revocability (refresh)। ਗ਼ਲਤ ਕਰਨਾ — ਇੱਕ ਲੰਬ-ਚਿਰਾ access token, ਕੋਈ rotation ਨਹੀਂ, refresh ਨੂੰ `localStorage` ਵਿੱਚ ਸਟੋਰ — ਇੱਕ ਲੀਕ ਹੋਏ token ਨੂੰ ਲੰਬ-ਚਿਰੇ account compromise ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਵੰਡ ਦਾ ਨਾਮ ਲੈਣਾ ਅਤੇ ਹਰ token ਤੁਹਾਨੂੰ ਕੀ ਦਿੰਦਾ ਹੈ ਇਹ ਦੱਸਣਾ ਹੀ ਉਹ ਹੈ ਜੋ ਇੱਕ security-ਸੁਚੇਤ ਇੰਜੀਨੀਅਰ ਤੋਂ ਜਾਣਨ ਦੀ ਉਮੀਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

	ਇੱਕ ਲੰਬ-ਚਿਰਾ access token	Access + refresh
ਉਜਾਗਰੀ	ਹਰ request 'ਤੇ ਭੇਜਿਆ, ਲੰਬਾ ਜੀਵੇ → ਵੱਡੀ ਚੋਰੀ ਦੀ ਵਿੰਡੋ	Access ਥੋੜ੍ਹ-ਚਿਰਾ; refresh ਘੱਟ ਭੇਜਿਆ
Revocation	ਔਖਾ (stateless JWT un-issue ਨਹੀਂ ਹੋ ਸਕਦਾ)	Refresh token revoke ਕਰੋ; access ਮਿੰਟਾਂ ਵਿੱਚ ਮਰ ਜਾਂਦਾ ਹੈ
UX	ਥੋੜ੍ਹ-ਚਿਰਾ ਹੋਵੇ ਤਾਂ ਵਾਰ-ਵਾਰ re-login	ਬਿਨਾਂ credential ਮੁੜ ਦਾਖ਼ਲ ਕੀਤੇ logged in ਰਹਿੰਦਾ ਹੈ
ਲੀਕ ਦਾ ਵਿਸਫੋਟ ਦਾਇਰਾ	ਵੱਡਾ	ਛੋਟਾ (access ਜਲਦੀ ਹੱਦ ਪਾਰ ਕਰਦਾ ਹੈ)

ਦੋ ਭੂਮਿਕਾਵਾਂ

ਸਿਰਫ਼ ਇੱਕ token ਕਿਉਂ ਨਹੀਂ?

ਇਹ ਵੰਡ ਕੀ ਸੰਭਵ ਕਰਦੀ ਹੈ

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

ਸੰਬੰਧਿਤ ਸਵਾਲ