وقتی یک وب‌سایت یا اپلیکیشن دارای سیستم ورود کاربران باشد، بعد از Login باید روشی وجود داشته باشد که سرور بتواند در درخواست‌های بعدی تشخیص دهد کاربر قبلاً احراز هویت شده است.
در سیستم‌های سنتی PHP معمولاً می‌توان از Session استفاده کرد؛ اما در بسیاری از APIها و اپلیکیشن‌های مدرن، روش‌های مبتنی بر Token نیز کاربرد زیادی دارند.
یکی از شناخته‌شده‌ترین روش‌ها در این زمینه JWT است.
JWT مخفف JSON Web Token است و می‌تواند برای انتقال اطلاعات قابل اعتبارسنجی بین Client و Server استفاده شود.
در این مقاله ابتدا بررسی می‌کنیم JWT چیست، از چه بخش‌هایی تشکیل شده، چگونه کار می‌کند و چه تفاوتی با Session دارد. سپس یک نمونه عملی از ساخت و اعتبارسنجی JWT در PHP را بررسی می‌کنیم.
# JWT چیست؟
JWT مخفف:
JSON Web Token
است.
JWT یک فرمت استاندارد و فشرده برای انتقال اطلاعات بین طرفین به صورت یک Token است.
یک JWT معمولاً به شکل زیر دیده می‌شود:
xxxxx.yyyyy.zzzzz
این Token از سه بخش تشکیل می‌شود:
Header.Payload.Signature
که با نقطه (.) از یکدیگر جدا شده‌اند.
به صورت ساده:
JWT
│
├── Header
├── Payload
└── Signature
# JWT چه کاربردی دارد؟
یکی از کاربردهای رایج JWT، احراز هویت در APIها است.
برای مثال:
User
↓
Login
↓
PHP API
↓
Check Email + Password
↓
Generate JWT
↓
Return Token
↓
Client
بعد از آن Client می‌تواند Token را در درخواست‌های بعدی ارسال کند:
Authorization: Bearer YOUR_TOKEN
سرور Token را دریافت و اعتبار آن را بررسی می‌کند.
اگر Token معتبر باشد، درخواست پردازش می‌شود.
# JWT چگونه کار می‌کند؟
فرض کنید کاربر با Email و Password وارد سیستم می‌شود.
ابتدا:
POST /api/login
و اطلاعاتی مانند زیر ارسال می‌شود:
{
"email": "user@example.com",
"password": "12345678"
}
سرور اطلاعات را بررسی می‌کند.
اگر رمز عبور صحیح باشد، یک JWT تولید می‌کند:
PHP API
↓
JWT
↓
Client
Client سپس Token را ذخیره می‌کند و در درخواست‌های بعدی ارسال می‌کند:
Authorization: Bearer eyJ...
سرور نیز JWT را اعتبارسنجی می‌کند.
# ساختار JWT چیست؟
یک JWT استاندارد سه بخش اصلی دارد:
Header.Payload.Signature
برای مثال:
eyJhbGciOiJIUzI1NiJ9
.
eyJzdWIiOiIxMjMifQ
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
این سه بخش عبارت‌اند از:
- Header
- Payload
- Signature
# Header در JWT چیست؟
Header معمولاً اطلاعاتی درباره نوع Token و الگوریتم مورد استفاده برای Signature دارد.
مثلاً:
{
"alg": "HS256",
"typ": "JWT"
}
در این مثال:
alg = HS256
الگوریتم Signature را مشخص می‌کند.
و:
typ = JWT
نوع Token را مشخص می‌کند.
# Payload در JWT چیست؟
Payload بخشی است که اطلاعات یا Claimهای Token داخل آن قرار می‌گیرند.
مثلاً:
{
"sub": "123",
"name": "Saeed",
"role": "user"
}
این اطلاعات را می‌توان در زمان اعتبارسنجی Token استخراج کرد.
اما یک نکته بسیار مهم وجود دارد:
Payload به صورت معمول رمزنگاری نمی‌شود.
JWT معمولی برای مخفی کردن اطلاعات طراحی نشده است.
بنابراین نباید اطلاعات حساس مانند موارد زیر را داخل Payload قرار دهیم:
Password
Credit Card Number
Private Secret
Database Password
# Signature در JWT چیست؟
بخش سوم JWT، Signature است.
Signature برای بررسی صحت و اعتبار Token استفاده می‌شود.
برای مثال در الگوریتم HS256 می‌توان به صورت مفهومی چنین چیزی داشت:
HMACSHA256(
Base64Url(Header) + "." + Base64Url(Payload),
Secret
)
اگر شخصی Payload را تغییر دهد، Signature دیگر با Token مطابقت نخواهد داشت.
بنابراین Server می‌تواند متوجه شود Token دستکاری شده است.
# آیا JWT رمزنگاری شده است؟
در حالت معمول، خیر.
این یکی از مهم‌ترین نکات درباره JWT است.
JWT معمولاً Signed است، نه Encrypted.
یعنی:
JWT
↓
Signature
↓
بررسی تغییر نکردن اطلاعات
نه اینکه:
JWT
↓
Encryption
↓
مخفی شدن اطلاعات
بنابراین اطلاعات حساس را داخل Payload قرار ندهید.
برای انتقال اطلاعات حساس نیز باید از HTTPS استفاده شود.
# Base64URL در JWT چیست؟
Header و Payload در JWT معمولاً به شکل Base64URL Encode شده‌اند.
برای مثال:
{
"alg": "HS256",
"typ": "JWT"
}
به یک رشته متنی تبدیل می‌شود.
نکته مهم این است که:
Base64 Encoding رمزنگاری نیست.
بنابراین هر کسی که Token را در اختیار داشته باشد، در حالت عادی می‌تواند Header و Payload را Decode کند.
چیزی که باید از آن محافظت شود، Secret Key و خود Token است.
# Claim در JWT چیست؟
اطلاعات داخل Payload معمولاً به عنوان Claim شناخته می‌شوند.
Claimها می‌توانند به دو دسته کلی تقسیم شوند:
- Registered Claims
- Custom Claims
برخی Claimهای استاندارد عبارت‌اند از:
iss
sub
aud
exp
nbf
iat
jti
# Claim به نام sub چیست؟
sub مخفف Subject است.
معمولاً برای مشخص کردن شناسه موضوع Token استفاده می‌شود.
برای Authentication می‌توان مثلاً شناسه کاربر را قرار داد:
{
"sub": "125"
}
یعنی این Token مربوط به کاربر شماره 125 است.
# Claim به نام iat چیست؟
iat مخفف:
Issued At
است.
یعنی زمان ایجاد Token.
مثلاً:
{
"iat": 1720000000
}
مقدار آن معمولاً به صورت Unix Timestamp است.
# Claim به نام exp چیست؟
exp مخفف:
Expiration Time
است.
یعنی زمانی که Token منقضی می‌شود.
مثلاً:
{
"sub": "125",
"exp": 1720003600
}
بعد از زمان تعیین‌شده، Token نباید معتبر در نظر گرفته شود.
استفاده از Expiration Time یکی از بخش‌های مهم مدیریت Token است.
# Claim به نام iss چیست؟
iss مخفف:
Issuer
است.
می‌توان از آن برای مشخص کردن صادرکننده Token استفاده کرد.
مثلاً:
{
"iss": "cmsnevis-api"
}
# Claim به نام aud چیست؟
aud مخفف:
Audience
است.
می‌تواند مشخص کند Token برای چه سرویس یا مخاطبی صادر شده است.
مثلاً:
{
"aud": "mobile-app"
}
# Claim به نام jti چیست؟
jti مخفف:
JWT ID
است.
می‌توان از آن برای اختصاص یک شناسه یکتا به هر Token استفاده کرد.
این موضوع در بعضی سیستم‌ها برای مدیریت یا Revocation Tokenها کاربرد دارد.
# JWT در PHP چگونه ساخته می‌شود؟
PHP به صورت Built-in یک تابع استاندارد برای تولید JWT ندارد.
در پروژه‌های واقعی معمولاً از یک کتابخانه معتبر استفاده می‌شود.
یکی از کتابخانه‌های شناخته‌شده در اکوسیستم PHP:
firebase/php-jwt
است.
اگر پروژه شما Composer داشته باشد، می‌توان پکیج را با Composer نصب کرد.
# نصب کتابخانه JWT با Composer
در ریشه پروژه PHP اجرا کنید:
composer require firebase/php-jwt
Composer کتابخانه و وابستگی‌های مورد نیاز را نصب می‌کند.
بعد از نصب معمولاً می‌توان Autoload Composer را وارد کرد:
require __DIR__ . '/vendor/autoload.php';
# Secret Key چیست؟
برای الگوریتم‌هایی مانند HS256 به یک Secret Key نیاز داریم.
مثلاً:
my-super-secret-key
اما در پروژه واقعی نباید Secret را به صورت مستقیم داخل کد قرار دهیم.
روش بهتر استفاده از Environment Variable است.
مثلاً:
JWT_SECRET=very-long-random-secret
و سپس:
$secret = $_ENV['JWT_SECRET'];
روش دقیق خواندن Environment Variable به ساختار پروژه و ابزار Configuration آن بستگی دارد.
# ساخت JWT در PHP
بعد از نصب کتابخانه، می‌توانیم یک Token ایجاد کنیم.
مثال:
<?php
require __DIR__ . '/vendor/autoload.php';
use Firebase\JWT\JWT;
$secret = $_ENV['JWT_SECRET'];
$payload = [
'iss' => 'cmsnevis-api',
'sub' => 123,
'iat' => time(),
'exp' => time() + 3600
];
$jwt = JWT::encode(
$payload,
$secret,
'HS256'
);
echo $jwt;
در این مثال Token برای مدت یک ساعت معتبر در نظر گرفته شده است.
# چرا نباید Secret را داخل Git قرار دهیم؟
فرض کنید کد زیر را داشته باشیم:
$secret = 'my-secret-key';
اگر این کد وارد Git Repository عمومی شود، Secret نیز افشا می‌شود.
روش بهتر این است که Secret در Environment Configuration قرار بگیرد.
مثلاً:
.env
و در:
.gitignore
قرار گیرد:
.env
تا اطلاعات حساس وارد Repository نشود.
# اعتبارسنجی JWT در PHP
تولید Token فقط یک بخش کار است.
در درخواست بعدی باید Token را دریافت و اعتبارسنجی کنیم.
فرض کنید Client این Header را ارسال کرده است:
Authorization: Bearer eyJ...
ابتدا Header را دریافت می‌کنیم.
در PHP:
$authorization = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
سپس باید Token را از قسمت Bearer جدا کنیم.
مثلاً:
if (!preg_match('/Bearer\s(\S+)/', $authorization, $matches)) {
http_response_code(401);
exit('Unauthorized');
}
$token = $matches[1];
حالا $token شامل JWT است.
# Decode کردن JWT در PHP
می‌توانیم Token را با کتابخانه JWT Decode کنیم:
<?php
require __DIR__ . '/vendor/autoload.php';
use Firebase\JWT\JWT;
use Firebase\JWT\Key;
$secret = $_ENV['JWT_SECRET'];
$decoded = JWT::decode(
$token,
new Key($secret, 'HS256')
);
در صورت معتبر بودن Token، اطلاعات Decode شده در اختیار برنامه قرار می‌گیرد.
مثلاً:
echo $decoded->sub;
می‌تواند شناسه کاربر را برگرداند.
# بررسی Expiration در JWT
اگر Token دارای:
{
"exp": 1720003600
}
باشد، کتابخانه می‌تواند منقضی شدن Token را بررسی کند.
بنابراین اگر Client یک Token قدیمی ارسال کند، Server نباید آن را معتبر در نظر بگیرد.
این موضوع یکی از دلایل مهم استفاده از exp در JWT است.
# مدیریت خطا هنگام Decode
در پروژه واقعی نباید فرض کنیم Token همیشه معتبر است.
ممکن است:
- Token خراب باشد.
- Signature اشتباه باشد.
- Token منقضی شده باشد.
- Algorithm مورد انتظار نباشد.
- ساختار Token صحیح نباشد.
بنابراین باید خطاها را مدیریت کنیم.
مثلاً:
try {
$decoded = JWT::decode(
$token,
new Key($secret, 'HS256')
);
} catch (Throwable $e) {
http_response_code(401);
echo json_encode([
'success' => false,
'message' => 'Invalid token'
]);
exit;
}
در محیط Production بهتر است جزئیات داخلی Exception را مستقیماً به Client نمایش ندهیم.
# ساخت Middleware ساده برای JWT
اگر Endpointهای زیادی داشته باشیم، نباید اعتبارسنجی JWT را در همه فایل‌ها تکرار کنیم.
می‌توانیم یک Middleware یا Helper ایجاد کنیم.
مثلاً:
src/
└── Middleware/
└── AuthMiddleware.php
وظیفه آن:
Request
↓
Read Authorization Header
↓
Extract Token
↓
Validate JWT
↓
Identify User
↓
Continue Request
در معماری‌های حرفه‌ای، این کار باعث می‌شود منطق Authentication از Controllerها جدا بماند.
# نمونه Middleware ساده JWT
یک نمونه ساده:
<?php
use Firebase\JWT\JWT;
use Firebase\JWT\Key;
function authenticateRequest(string $secret): object
{
$authorization = $_SERVER['HTTP_AUTHORIZATION'] ?? '';
if (!preg_match(
'/Bearer\s(\S+)/',
$authorization,
$matches
)) {
http_response_code(401);
exit('Unauthorized');
}
$token = $matches[1];
try {
return JWT::decode(
$token,
new Key($secret, 'HS256')
);
} catch (Throwable $e) {
http_response_code(401);
exit('Invalid token');
}
}
حالا در Endpoint:
$user = authenticateRequest($secret);
echo $user->sub;
می‌توان شناسه کاربر احراز هویت‌شده را دریافت کرد.
# JWT و REST API
JWT یکی از روش‌هایی است که می‌توان برای Authentication در REST API استفاده کرد.
مثلاً:
POST /api/login
پاسخ:
{
"access_token": "eyJ..."
}
Client سپس درخواست می‌دهد:
GET /api/profile
Authorization: Bearer eyJ...
Server:
Authorization Header
↓
Extract Token
↓
Verify Signature
↓
Check Expiration
↓
Identify User
↓
Return Data
# Access Token چیست؟
Access Token توکنی است که Client برای دسترسی به منابع محافظت‌شده ارسال می‌کند.
مثلاً:
Authorization: Bearer ACCESS_TOKEN
در سیستم JWT، این Access Token می‌تواند همان JWT باشد.
# Refresh Token چیست؟
اگر Access Token عمر کوتاهی داشته باشد، کاربر بعد از انقضا مجبور می‌شود دوباره Login کند.
برای حل این مشکل در برخی معماری‌ها از Refresh Token استفاده می‌شود.
ساختار مفهومی:
Login
↓
Access Token
↓
Refresh Token
Access Token:
عمر کوتاه‌تر
Refresh Token:
عمر طولانی‌تر
وقتی Access Token منقضی شود، Client می‌تواند طبق طراحی سیستم از Refresh Token برای دریافت Access Token جدید استفاده کند.
# آیا Refresh Token حتماً باید JWT باشد؟
خیر.
Refresh Token می‌تواند یک Token تصادفی و غیرقابل حدس باشد که Server آن را در دیتابیس یا سیستم ذخیره‌سازی مناسب مدیریت می‌کند.
بنابراین نباید تصور کنیم که تمام Tokenهای Authentication حتماً باید JWT باشند.
# JWT Stateless چیست؟
یکی از ویژگی‌هایی که درباره JWT زیاد مطرح می‌شود، Stateless بودن است.
در یک مدل Stateless، Server لازم نیست برای هر Access Token یک Session سنتی در حافظه یا دیتابیس نگه دارد.
اطلاعات لازم برای اعتبارسنجی Token در خود Token و Signature آن وجود دارد.
به صورت ساده:
Client
|
| JWT
↓
Server
|
| Verify Signature
↓
Accept / Reject
اما این به معنی حذف کامل State از تمام سیستم نیست.
برای مثال اگر سیستم Refresh Token، Logout سراسری، Revocation یا Session Management داشته باشد، ممکن است همچنان به Storage سمت Server نیاز داشته باشد.
# JWT و Session چه تفاوتی دارند؟
این یکی از مهم‌ترین سوالات در Authentication است.
| ویژگی | Session | JWT |
|---|---|---|
| محل نگهداری وضعیت | معمولاً Server | اطلاعات اصلی در Token |
| مناسب برای | Web Appهای سنتی | API و معماری‌های Token-Based |
| نیاز به Session Store | معمولاً بله | برای Access Token الزاماً نه |
| ارسال در درخواست | معمولاً Cookie | معمولاً Authorization Header |
| Stateless بودن | معمولاً خیر | می‌تواند باشد |
| مدیریت Revocation | نسبتاً ساده‌تر | نیازمند طراحی بیشتر |
این جدول به این معنی نیست که JWT همیشه بهتر از Session است.
انتخاب روش به معماری پروژه، نوع Client، نیازهای امنیتی و نحوه مدیریت Session بستگی دارد.
# JWT چه مزایایی دارد؟
برخی مزایای JWT عبارت‌اند از:
- مناسب برای APIها
- قابلیت استفاده بین سرویس‌های مختلف
- ساختار استاندارد
- امکان قرار دادن Claimهای مشخص
- قابلیت اعتبارسنجی Signature
- امکان طراحی Stateless برای Access Token
- عدم نیاز اجباری به Session Server-Side برای هر Access Token
# JWT چه معایبی دارد؟
JWT نیز محدودیت‌هایی دارد.
1. لغو Token دشوارتر است
اگر JWT مدت زیادی اعتبار داشته باشد و بخواهید قبل از Expiration آن را باطل کنید، باید مکانیزم مناسبی برای Revocation طراحی کنید.
2. حجم Token
JWT معمولاً از یک Session ID ساده بزرگ‌تر است.
3. Payload محرمانه نیست
نباید اطلاعات حساس داخل آن قرار داد.
4. مدیریت Refresh Token
در سیستم‌های حرفه‌ای ممکن است به Access Token و Refresh Token نیاز داشته باشید و این موضوع معماری را پیچیده‌تر می‌کند.
5. سرقت Token
اگر Access Token در اختیار مهاجم قرار بگیرد، تا زمانی که معتبر است ممکن است بتواند از آن استفاده کند.
به همین دلیل حفاظت از Token بسیار مهم است.
# JWT و HTTPS
یکی از مهم‌ترین اصول استفاده از JWT این است که API باید از HTTPS استفاده کند.
فرض کنید Token شما:
eyJhbGciOi...
باشد.
اگر این Token در یک ارتباط ناامن ارسال شود، مهاجم ممکن است بتواند آن را سرقت کند.
بنابراین:
HTTP
برای انتقال اطلاعات حساس مناسب نیست.
از:
HTTPS
استفاده کنید.
# آیا JWT را در LocalStorage ذخیره کنیم؟
این موضوع به معماری و مدل تهدید پروژه بستگی دارد و یک پاسخ واحد برای همه پروژه‌ها وجود ندارد.
ذخیره Token در localStorage می‌تواند در صورت وجود آسیب‌پذیری XSS خطرناک باشد، زیرا JavaScript صفحه می‌تواند به آن دسترسی داشته باشد.
در بعضی معماری‌های وب، استفاده از Cookieهای امن و HttpOnly می‌تواند گزینه مناسبی باشد، اما در این حالت باید موضوعاتی مانند CSRF نیز به شکل صحیح مدیریت شوند.
بنابراین انتخاب محل ذخیره Token باید بر اساس معماری Frontend، نوع API و مدل تهدید انجام شود.
# JWT و XSS
اگر مهاجم بتواند JavaScript مخرب را در سایت اجرا کند، ممکن است بتواند به Tokenهایی که از طریق JavaScript قابل دسترسی هستند دسترسی پیدا کند.
به همین دلیل باید از XSS جلوگیری کرد.
مثلاً در نمایش داده‌های کاربر در HTML باید خروجی را متناسب با Context Encode کنیم:
echo htmlspecialchars(
$username,
ENT_QUOTES,
'UTF-8'
);
همچنین Content Security Policy و سایر کنترل‌های امنیتی می‌توانند در کاهش ریسک XSS نقش داشته باشند.
# JWT و CSRF
اگر JWT را در Cookie قرار دهید، مرورگر ممکن است آن Cookie را در درخواست‌های مناسب ارسال کند.
در این حالت باید ملاحظات CSRF را جدی بگیرید.
در مقابل، اگر Token را در Authorization Header قرار دهید و JavaScript آن را به صورت صریح ارسال کند، مدل CSRF متفاوت خواهد بود.
بنابراین نوع ذخیره و ارسال Token روی طراحی امنیتی API تأثیر دارد.
# JWT را چه زمانی استفاده کنیم؟
JWT می‌تواند در سناریوهایی مانند موارد زیر مفید باشد:
- REST API
- اپلیکیشن موبایل
- ارتباط بین سرویس‌ها
- معماری‌های توزیع‌شده
- سیستم‌هایی که Clientهای مختلف دارند
- APIهایی که نیاز به Token-Based Authentication دارند
اما استفاده از JWT فقط به دلیل محبوب بودن آن دلیل کافی برای انتخابش نیست.
ابتدا معماری سیستم و نیازهای امنیتی را بررسی کنید.
# JWT را چه زمانی استفاده نکنیم؟
اگر یک وب‌سایت ساده Server-Side Rendered دارید و فقط به Login معمولی نیاز دارید، Session و Cookie می‌توانند معماری ساده‌تری ایجاد کنند.
مثلاً:
PHP Website
+
Traditional Login
+
Session
+
Cookie
در چنین سناریویی ممکن است نیازی به JWT وجود نداشته باشد.
# JWT در Laravel
در Laravel نیز می‌توان سیستم Authentication برای API طراحی کرد.
اما Laravel به صورت پیش‌فرض الزام نمی‌کند که حتماً از JWT استفاده کنید.
بسته به معماری پروژه می‌توان از راهکارهای مختلفی برای Authentication API استفاده کرد.
بنابراین بهتر است ابتدا مفهوم JWT و Token Authentication را با PHP درک کنید و سپس روش مناسب را در Laravel انتخاب کنید.
# یک معماری کامل JWT Authentication
یک معماری ساده می‌تواند چنین ساختاری داشته باشد:
Client
|
| Email + Password
↓
Login Endpoint
|
↓
Verify Password Hash
|
↓
Create JWT
|
↓
Client
|
| Bearer Token
↓
Protected Endpoint
|
↓
Validate JWT
|
↓
Identify User
|
↓
Response
این ساختار پایه بسیاری از APIهای Token-Based است.
# نکات امنیتی مهم هنگام استفاده از JWT
برای استفاده صحیح از JWT چند نکته بسیار مهم است:
1. Secret قوی استفاده کنید
Secret باید غیرقابل حدس و به اندازه کافی طولانی باشد.
2. Secret را داخل Git قرار ندهید
آن را در Environment یا Secret Management مناسب نگهداری کنید.
3. HTTPS استفاده کنید
Token باید در یک ارتباط امن منتقل شود.
4. Token را بیش از حد طولانی معتبر نکنید
Access Token با عمر کوتاه‌تر معمولاً ریسک سرقت طولانی‌مدت را کاهش می‌دهد.
5. Payload را محرمانه فرض نکنید
اطلاعات حساس را داخل JWT قرار ندهید.
6. Algorithm را صریح مدیریت کنید
Server نباید صرفاً به اطلاعات کنترل‌شده توسط Client برای انتخاب الگوریتم اعتماد کند.
7. Token را در Log ذخیره نکنید
ثبت کامل Access Token در Log می‌تواند یک ریسک امنیتی جدی ایجاد کند.
8. Refresh Token را جداگانه مدیریت کنید
در صورت استفاده از Refresh Token، چرخه عمر و Revocation آن را مشخص کنید.
9. Logout را فراموش نکنید
در معماری JWT باید از ابتدا مشخص کنید Logout و ابطال Token چگونه انجام می‌شود.
# تفاوت JWT با API Key
JWT و API Key یکی نیستند.
API Key معمولاً یک شناسه یا Secret ثابت‌تر برای شناسایی Client یا دسترسی به یک سرویس است.
JWT معمولاً شامل Claimها، زمان انقضا و Signature است.
مثلاً:
API Key
↓
Identify Client
در حالی که:
JWT
↓
Claims
↓
Signature
↓
Expiration
↓
Identify / Authorize
البته کاربرد دقیق هر دو به معماری سیستم بستگی دارد.
# آیا JWT جایگزین کامل Session است؟
خیر.
JWT و Session دو روش متفاوت برای مدیریت Authentication هستند.
Session برای بسیاری از وب‌سایت‌های سنتی انتخاب ساده و مناسبی است.
JWT نیز برای برخی APIها و معماری‌های Token-Based کاربرد زیادی دارد.
به جای اینکه همیشه یکی را بهتر بدانیم، باید بر اساس نیاز پروژه انتخاب کنیم.
# جمع‌بندی
JWT یا JSON Web Token یکی از روش‌های شناخته‌شده برای انتقال اطلاعات قابل اعتبارسنجی بین Client و Server است.
یک JWT از سه بخش تشکیل می‌شود:
Header.Payload.Signature
Header الگوریتم و نوع Token را مشخص می‌کند.
Payload شامل Claimها است.
Signature برای بررسی صحت Token استفاده می‌شود.
در PHP می‌توان با استفاده از کتابخانه‌هایی مانند firebase/php-jwt JWT ایجاد و اعتبارسنجی کرد.
یک جریان معمول Authentication با JWT به شکل زیر است:
Login
↓
Verify Password
↓
Generate JWT
↓
Client
↓
Authorization: Bearer TOKEN
↓
Verify JWT
↓
Access Protected Resource
با این حال JWT راه‌حل جادویی برای Authentication نیست. باید مواردی مانند HTTPS، مدیریت Secret، Expiration، XSS، CSRF، Token Revocation و Refresh Token را متناسب با معماری پروژه در نظر گرفت.
# سوالات متداول درباره JWT در PHP
JWT در PHP چیست؟
JWT یک Token ساختاریافته است که می‌تواند برای انتقال اطلاعات قابل اعتبارسنجی بین Client و Server استفاده شود و یکی از کاربردهای رایج آن Authentication در APIها است.
JWT از چه بخش‌هایی تشکیل شده است؟
JWT معمولاً از سه بخش Header، Payload و Signature تشکیل شده که با نقطه از یکدیگر جدا می‌شوند.
آیا Payload در JWT رمزنگاری شده است؟
خیر. JWT معمولی برای محرمانه‌سازی Payload طراحی نشده است و اطلاعات آن را نباید حساس یا محرمانه در نظر گرفت.
آیا JWT برای Authentication مناسب است؟
JWT می‌تواند برای Authentication در APIها و سیستم‌های Token-Based مناسب باشد، اما انتخاب آن باید بر اساس معماری و نیازهای امنیتی پروژه انجام شود.
JWT بهتر است یا Session؟
هیچ پاسخ عمومی برای همه پروژه‌ها وجود ندارد. Session برای بسیاری از وب‌سایت‌های سنتی مناسب است و JWT می‌تواند برای برخی APIها و Clientهای مختلف کاربرد مناسبی داشته باشد.
آیا JWT را می‌توان با PHP ساخت؟
بله. PHP به صورت Built-in استاندارد مشخصی برای JWT ندارد، اما می‌توان از کتابخانه‌های معتبر PHP مانند firebase/php-jwt استفاده کرد.
Access Token و Refresh Token چه تفاوتی دارند؟
Access Token معمولاً برای دسترسی به Resourceهای محافظت‌شده استفاده می‌شود و عمر کوتاه‌تری دارد. Refresh Token برای دریافت Access Token جدید در معماری‌هایی که از آن استفاده می‌کنند به کار می‌رود.
آیا JWT باید در HTTPS ارسال شود؟
بله. Tokenهای Authentication باید از طریق ارتباط امن HTTPS منتقل شوند تا خطر شنود و سرقت Token کاهش پیدا کند.
آیا JWT جایگزین Session است؟
JWT می‌تواند در بعضی معماری‌ها جایگزین مدل سنتی Session شود، اما جایگزین عمومی و ضروری برای Session نیست. انتخاب بین آن‌ها به نوع پروژه و معماری سیستم بستگی دارد.
