اگر با APIها کار کرده باشید، احتمالاً با مفاهیمی مانند Access Token، Refresh Token، JWT، Bearer Token و Authentication روبهرو شدهاید.
اما یک سؤال مهم وجود دارد:
وقتی یک اپلیکیشن میخواهد به اطلاعات کاربر در یک سرویس دیگر دسترسی داشته باشد، بدون اینکه Password کاربر را دریافت کند، چه کاری باید انجام دهد؟
اینجاست که OAuth 2.0 وارد میشود.
برای مثال تصور کنید یک سایت میخواهد به Google متصل شود و کاربر بتواند با حساب Google خود وارد سیستم شود. سایت شما نباید Password حساب Google کاربر را دریافت کند.
بهجای آن، کاربر به سرویس Google منتقل میشود، دسترسی موردنظر را تأیید میکند و در نهایت یک Authorization Code یا Token در اختیار سیستم شما قرار میگیرد.
در این مقاله با OAuth 2.0، اجزای آن، Flowهای مختلف، Access Token، Refresh Token، PKCE و نحوه پیادهسازی مفاهیم آن در PHP آشنا میشویم.
# OAuth 2.0 چیست؟
OAuth 2.0 یک Authorization Framework برای اعطای دسترسی محدود به یک Resource است.
نکته بسیار مهم:
> OAuth 2.0 در اصل برای Authorization طراحی شده است، نه اینکه خودش یک سیستم Authentication کامل باشد.
یعنی OAuth مشخص میکند:
چه Clientای
به چه Resourceای
با چه سطح دسترسی
و با چه Tokenای
دسترسی داشته باشد.
برای مثال:
کاربر
↓
اجازه دسترسی
↓
Application
↓
Access Token
↓
API
# یک مثال واقعی از OAuth
فرض کنید یک سرویس به نام:
MyApp
داریم.
کاربر میخواهد MyApp بتواند اطلاعات خاصی از حساب Google او را بخواند.
مدل اشتباه این است:
MyApp
↓
Password Google را بگیر
↓
با Password وارد Google شو
این طراحی خطرناک است.
در OAuth:
User
↓
MyApp
↓
Authorization Server
↓
User Login
↓
User Consent
↓
Authorization Code
↓
MyApp
↓
Access Token
↓
Resource Server
MyApp هیچوقت Password کاربر را دریافت نمیکند.
# اجزای اصلی OAuth 2.0
برای درک OAuth باید چهار نقش اصلی آن را بشناسیم.
1. Resource Owner
Resource Owner معمولاً همان User است.
مثلاً:
User
که مالک اطلاعات است.
2. Client
Client همان Applicationای است که میخواهد به Resource دسترسی پیدا کند.
مثلاً:
Web Application
Mobile Application
Backend Service
3. Authorization Server
Authorization Server مسئول مواردی مانند:
Login
Consent
Authorization
Authorization Code
Access Token
Refresh Token
است.
4. Resource Server
Resource Server همان سروری است که Resource واقعی را نگهداری میکند.
مثلاً:
/api/profile
/api/orders
/api/photos
Access Token توسط این Server بررسی میشود.
# تصویر ذهنی ساده OAuth
ساختار را میتوان اینگونه تصور کرد:
┌─────────────────┐
│ User │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Client │
└────────┬────────┘
│
▼
┌──────────────────────┐
│ Authorization Server │
└──────────┬───────────┘
│
Access Token
│
▼
┌──────────────────────┐
│ Resource Server │
└──────────────────────┘
# OAuth با JWT چه تفاوتی دارد؟
این دو مفهوم را نباید یکی در نظر گرفت.
OAuth 2.0 یک Framework برای Authorization است.
JWT یک Token Format است.
ممکن است Access Token یک سیستم OAuth به شکل JWT باشد.
اما الزامی نیست.
برای مثال:
OAuth 2.0
↓
Access Token
↓
JWT
یا:
OAuth 2.0
↓
Access Token
↓
Opaque Token
بنابراین:
OAuth ≠ JWT
# OAuth با Login معمولی چه تفاوتی دارد؟
در Login معمولی:
User
↓
Username + Password
↓
Your Application
اما در OAuth:
User
↓
Authorization Server
↓
Consent
↓
Authorization Code
↓
Access Token
Password کاربر به Client داده نمیشود.
# Scope چیست؟
Scope مشخص میکند Client چه سطحی از دسترسی را درخواست کرده است.
مثلاً:
profile
email
read_orders
write_orders
فرض کنید Application فقط نیاز دارد Email کاربر را بخواند.
بهجای درخواست دسترسی کامل:
*
فقط:
email
درخواست میشود.
اصل مهم:
> حداقل دسترسی لازم را درخواست کنید.
# مثال Scope
فرض کنیم API ما این Scopeها را دارد:
users:read
users:write
orders:read
orders:write
یک Client ممکن است فقط این موارد را دریافت کند:
users:read
orders:read
در نتیجه اگر Client به Endpoint تغییر سفارش دسترسی پیدا کند:
POST /api/orders
باید بررسی شود که Scope مناسب را دارد یا خیر.
# Access Token چیست؟
Access Token مجوز دسترسی به Resource Server است.
مثلاً:
GET /api/profile
Authorization: Bearer ACCESS_TOKEN
Resource Server Token را دریافت کرده و بررسی میکند:
Token معتبر است؟
↓
منقضی نشده؟
↓
Revoked نشده؟
↓
Scope مناسب دارد؟
↓
User اجازه دسترسی دارد؟
اگر همه موارد درست باشد، درخواست پردازش میشود.
# Access Token نباید عمر بسیار طولانی داشته باشد
بهتر است Access Token عمر محدودی داشته باشد.
مثلاً:
Access Token
↓
15 دقیقه
یا:
Access Token
↓
30 دقیقه
مقدار مناسب به نوع سیستم و سطح ریسک آن بستگی دارد.
# Refresh Token چیست؟
اگر Access Token کوتاهمدت باشد، پس کاربر مجبور است مرتب Login کند؟
خیر.
اینجاست که Refresh Token استفاده میشود.
مدل کلی:
Login / Authorization
↓
Access Token
+
Refresh Token
↓
Access Token Expired
↓
Refresh Token
↓
New Access Token
Refresh Token معمولاً عمر بیشتری از Access Token دارد.
# تفاوت Access Token و Refresh Token
| ویژگی | Access Token | Refresh Token |
|---|---|---|
| استفاده اصلی | دسترسی به API | دریافت Access Token جدید |
| عمر | کوتاهتر | طولانیتر |
| ارسال به API | بله | معمولاً خیر |
| حساسیت | بالا | بسیار بالا |
| Rotation | بسته به معماری | توصیهشده |
| Revocation | مهم | بسیار مهم |
Refresh Token نباید برای دسترسی مستقیم به تمام APIها استفاده شود.
# Authorization Code Flow چیست؟
یکی از مهمترین Flowهای OAuth 2.0، Authorization Code Flow است.
مراحل کلی:
1. Client
↓
2. Authorization Server
↓
3. Login + Consent
↓
4. Authorization Code
↓
5. Client Backend
↓
6. Token Endpoint
↓
7. Access Token
این روش برای بسیاری از Applicationهای Web مناسب است.
# مرحله اول: Redirect به Authorization Server
Client کاربر را به Authorization Endpoint میفرستد.
مثلاً:
https://auth.example.com/authorize
با پارامترهایی مانند:
client_id
redirect_uri
response_type
scope
state
نمونه:
https://auth.example.com/authorize?
client_id=123
&redirect_uri=https://app.example.com/callback
&response_type=code
&scope=profile
&state=xyz
# client_id چیست؟
client_id شناسه Application است.
مثلاً:
client_id = app_12345
این مقدار بهتنهایی Secret نیست.
اما Clientهای Confidential معمولاً یک client_secret نیز دارند.
# redirect_uri چیست؟
بعد از اتمام Authorization، Authorization Server باید کاربر را به آدرس مشخصی برگرداند.
مثلاً:
https://app.example.com/oauth/callback
این URL باید از قبل ثبت شده باشد.
نباید اجازه دهیم Client هر Redirect URI دلخواهی ارسال کند.
# چرا Redirect URI مهم است؟
اگر Server هر URLای را قبول کند، مهاجم میتواند URL مخربی ارائه کند:
https://attacker.example/callback
و در شرایط نامناسب Authorization Code را به سمت خودش هدایت کند.
به همین دلیل Redirect URI باید با مقادیر ثبتشده مقایسه شود.
# state چیست؟
پارامتر state برای جلوگیری از حملاتی مانند CSRF در OAuth Flow اهمیت دارد.
Client یک مقدار تصادفی ایجاد میکند:
$state = bin2hex(random_bytes(32));
آن را در Session ذخیره میکند:
$_SESSION['oauth_state'] = $state;
و سپس در Authorization Request ارسال میکند.
پس از برگشت:
$receivedState = $_GET['state'] ?? '';
if (
!hash_equals(
$_SESSION['oauth_state'] ?? '',
$receivedState
)
) {
http_response_code(400);
exit('Invalid state');
}
به این ترتیب Request باید با Authorization Request اولیه مطابقت داشته باشد.
# Authorization Code چیست؟
پس از Login و Consent، Authorization Server معمولاً یک Code به Client میدهد:
https://app.example.com/callback?code=abc123
این Code خود Access Token نیست.
Client باید آن را به Token Endpoint ارسال کند.
# مرحله Token Exchange
Client:
Authorization Code
↓
Token Endpoint
↓
Access Token
+
Refresh Token
برای مثال:
POST /oauth/token
Content-Type: application/x-www-form-urlencoded
با دادههایی مانند:
grant_type=authorization_code
code=abc123
redirect_uri=https://app.example.com/callback
client_id=app_123
در Clientهای Confidential ممکن است Authentication مربوط به Client نیز لازم باشد.
# چرا مستقیماً Access Token را در URL نمیدهیم؟
بهدلیل خطر افشای Token در:
Browser History
Logs
Referrer
Proxy
Analytics
Authorization Code Flow بهجای قرار دادن مستقیم Access Token در Redirect، ابتدا یک Code کوتاهعمر میدهد.
سپس Client آن Code را با Token Endpoint مبادله میکند.
# PKCE چیست؟
PKCE یکی از مهمترین مکانیزمهای امنیتی OAuth 2.0 است.
PKCE بیشتر برای Clientهایی اهمیت دارد که نمیتوانند Secret را بهصورت امن نگهداری کنند، مانند:
Mobile Apps
SPA
Desktop Apps
PKCE با دو مقدار اصلی کار میکند:
code_verifier
code_challenge
# ساخت code_verifier در PHP
برای تولید مقدار تصادفی:
$codeVerifier = rtrim(
strtr(
base64_encode(random_bytes(32)),
'+/',
'-_'
),
'='
);
سپس Code Challenge ساخته میشود:
$codeChallenge = rtrim(
strtr(
base64_encode(
hash(
'sha256',
$codeVerifier,
true
)
),
'+/',
'-_'
),
'='
);
در Authorization Request:
code_challenge
code_challenge_method=S256
ارسال میشود.
# چرا PKCE امنیت را افزایش میدهد؟
فرض کنیم Authorization Code توسط مهاجم به دست بیاید.
مهاجم هنوز code_verifier را ندارد.
در نتیجه نمیتواند بهسادگی Code را به Access Token تبدیل کند.
مدل:
Authorization Request
↓
code_challenge
↓
Authorization Code
↓
Token Request
+
code_verifier
↓
Access Token
# Client Credentials Flow
این Flow برای زمانی مناسب است که یک Application خودش میخواهد با API ارتباط برقرار کند و User مشخصی در جریان نیست.
مثلاً:
Service A
↓
Service B
Client با Credential خودش Token میگیرد:
client_id
client_secret
و سپس:
Access Token
دریافت میکند.
این مدل برای ارتباط Server-to-Server کاربرد زیادی دارد.
# Client Credentials در PHP
یک درخواست نمونه:
$ch = curl_init('https://auth.example.com/oauth/token');
curl_setopt_array($ch, [
CURLOPT_POST => true,
CURLOPT_POSTFIELDS => http_build_query([
'grant_type' => 'client_credentials',
'scope' => 'orders:read',
]),
CURLOPT_HTTPHEADER => [
'Content-Type: application/x-www-form-urlencoded',
'Authorization: Basic ' . base64_encode(
$clientId . ':' . $clientSecret
),
],
CURLOPT_RETURNTRANSFER => true,
]);
$response = curl_exec($ch);
curl_close($ch);
پاسخ میتواند شبیه این باشد:
{
"access_token": "ACCESS_TOKEN",
"token_type": "Bearer",
"expires_in": 1800,
"scope": "orders:read"
}
# Password Grant چیست؟
در OAuth 2.0 قدیمی Flowای با نام Resource Owner Password Credentials وجود داشت که Client مستقیماً Username و Password کاربر را دریافت میکرد.
در معماریهای جدید نباید بهعنوان انتخاب پیشفرض سراغ آن رفت.
مشکل اصلی این مدل این است که:
User Password
↓
Client
↓
Authorization Server
در نتیجه Client باید Password کاربر را دریافت کند.
یکی از اهداف OAuth این است که Client برای دسترسی به Resource نیازی به دریافت Password سرویس اصلی نداشته باشد.
# Implicit Flow چیست؟
Implicit Flow نیز یکی از Flowهای قدیمی OAuth 2.0 است که Access Token را مستقیماً در سمت Browser دریافت میکرد.
در معماریهای جدید معمولاً Authorization Code Flow به همراه PKCE گزینه مناسبتری برای Clientهایی است که نمیتوانند Secret را امن نگه دارند.
# OAuth 2.0 در PHP چگونه پیادهسازی میشود؟
برای ساخت یک سیستم OAuth میتوانیم اجزای زیر را داشته باشیم:
/oauth/authorize
/oauth/token
/oauth/revoke
و جداولی مانند:
oauth_clients
oauth_authorization_codes
oauth_access_tokens
oauth_refresh_tokens
oauth_scopes
# جدول oauth_clients
ساختار ساده:
id
client_id
client_secret_hash
name
redirect_uris
grant_types
created_at
revoked_at
برای Clientهای Confidential باید Secret بهشکل امن مدیریت شود.
# جدول Authorization Code
مثلاً:
oauth_authorization_codes
با فیلدهای:
id
code_hash
client_id
user_id
redirect_uri
scope
expires_at
used_at
created_at
نکته مهم:
Authorization Code باید:
- کوتاهعمر باشد
- یکبار مصرف باشد
- به Client متصل باشد
- به Redirect URI متصل باشد
# ذخیره Authorization Code
بهتر است Code خام را در دیتابیس نگهداری نکنیم.
مثلاً:
$code = bin2hex(random_bytes(32));
$codeHash = hash('sha256', $code);
و Hash را ذخیره کنیم.
# جدول Access Token
مثلاً:
oauth_access_tokens
با:
id
token_hash
client_id
user_id
scope
expires_at
revoked_at
created_at
Access Token نیز در صورت امکان بهتر است بهصورت Hash ذخیره شود.
# Refresh Token
Refresh Token نیز باید بهصورت امن ذخیره شود:
oauth_refresh_tokens
مثلاً:
id
token_hash
client_id
user_id
scope
expires_at
revoked_at
created_at
# Refresh Token Rotation
یکی از روشهای مهم برای افزایش امنیت Refresh Token، Rotation است.
فرض کنیم:
Refresh Token A
مصرف شد.
Server بهجای اینکه همان Token را دوباره معتبر نگه دارد:
Refresh Token A
↓
Consumed
↓
Refresh Token B
تولید میکند.
اگر Token قدیمی دوباره استفاده شود، Server میتواند آن را بهعنوان رفتار مشکوک در نظر بگیرد.
# Token Revocation
سیستم باید بتواند Token را باطل کند.
مثلاً:
UPDATE oauth_access_tokens
SET revoked_at = NOW()
WHERE id = ?
در شرایطی مانند:
Logout
Password Change
Account Compromise
Admin Action
Client Revocation
میتوان Tokenها را Revoked کرد.
# Scope را در هر Request بررسی کنید
داشتن Access Token به معنی دسترسی به تمام API نیست.
مثلاً:
Token Scope:
orders:read
درخواست:
GET /api/orders
میتواند مجاز باشد.
اما:
DELETE /api/orders/10
ممکن است به Scope دیگری نیاز داشته باشد:
orders:delete
# بررسی Scope در PHP
مثلاً:
function hasScope(
array $scopes,
string $requiredScope
): bool {
return in_array(
$requiredScope,
$scopes,
true
);
}
سپس:
if (!hasScope($tokenScopes, 'orders:read')) {
http_response_code(403);
echo json_encode([
'message' => 'Forbidden'
]);
exit;
}
# OAuth و Authorization با هم
حتی Scope نیز جایگزین Authorization کامل نیست.
مثلاً:
Scope:
orders:read
داریم.
اما کاربر فقط باید سفارشهای خودش را ببیند.
پس باید هر دو بررسی شوند:
Valid Token
↓
Required Scope
↓
User Permission
↓
Resource Ownership
# OAuth و BOLA / IDOR
فرض کنید Token کاربر معتبر است:
User = 25
Scope = orders:read
درخواست:
GET /api/orders/500
باید بررسی کنیم:
Order 500
↓
user_id = 25 ?
اگر متعلق به User دیگری باشد:
403 Forbidden
یا در بعضی معماریها برای جلوگیری از افشای وجود Resource، پاسخ مناسبی مانند 404 انتخاب میشود.
# OAuth و HTTPS
OAuth بدون HTTPS در Production طراحی مناسبی ندارد.
اطلاعات حساس OAuth شامل:
Authorization Code
Access Token
Refresh Token
Client Secret
نباید از طریق ارتباط ناامن منتقل شوند.
# Client Secret را کجا نگهداری کنیم؟
Client Secret نباید در مواردی مانند این قرار گیرد:
JavaScript Frontend
Mobile App Source
Git Repository
Public Config
Clientهای عمومی مانند SPA و Mobile App اصولاً نمیتوانند Secret را مانند یک Backend Server محرمانه نگه دارند.
برای این Clientها استفاده از PKCE اهمیت ویژهای دارد.
# OAuth برای SPA
برای Single Page Application معمولاً نمیتوان Secret را مانند Backend مخفی کرد.
بنابراین معماری رایج:
SPA
↓
Authorization Code
+
PKCE
↓
Authorization Server
↓
Access Token
است.
# OAuth برای Mobile App
در Mobile Application نیز:
Mobile App
↓
Authorization Server
↓
Login
↓
Authorization Code
↓
PKCE
↓
Access Token
استفاده از PKCE اهمیت زیادی دارد.
# OAuth و Session چه تفاوتی دارند؟
Session Authentication معمولاً چنین مدلی دارد:
Browser
↓
Session Cookie
↓
Your Website
OAuth بیشتر برای Delegated Authorization و ارتباط بین Client و Resource/Authorization Server طراحی شده است.
ممکن است یک سیستم همزمان از Session برای پنل وب و OAuth برای API استفاده کند.
# OAuth و OpenID Connect
یکی از موضوعات مهم این است که OAuth 2.0 بهتنهایی برای استانداردسازی Login طراحی نشده است.
برای Authentication استاندارد روی OAuth معمولاً از OpenID Connect یا OIDC استفاده میشود.
OIDC روی OAuth 2.0 ساخته شده و مفاهیمی مانند:
ID Token
UserInfo
OpenID Scope
را اضافه میکند.
به همین دلیل هنگام صحبت درباره:
Login with Google
Login with Microsoft
Login with another Identity Provider
معمولاً با OAuth 2.0 + OpenID Connect روبهرو میشویم.
# اشتباهات رایج در OAuth 2.0
1. تصور اینکه OAuth همان Login است
OAuth در اصل Framework مربوط به Authorization است.
2. استفاده از JWT بهعنوان جایگزین OAuth
JWT و OAuth دو مفهوم متفاوت هستند.
3. عدم استفاده از state
در Authorization Code Flow باید state بهدرستی مدیریت شود.
4. استفاده نکردن از PKCE
برای Public Clientها مانند SPA و Mobile App، PKCE اهمیت زیادی دارد.
5. Redirect URI آزاد
نباید Client بتواند هر Redirect URI دلخواهی ارسال کند.
6. Access Token با عمر بسیار طولانی
Token کوتاهعمر معمولاً ریسک سوءاستفاده طولانیمدت را کاهش میدهد.
7. عدم Rotation Refresh Token
Refresh Tokenهای بلندمدت باید با دقت بسیار بیشتری مدیریت شوند.
8. ثبت Token در Log
این کار میتواند باعث افشای Credential شود.
9. قرار دادن Secret در Frontend
Frontend محل مناسبی برای نگهداری Secret محرمانه نیست.
10. عدم بررسی Scope
Token معتبر به معنی دسترسی به همه Endpointها نیست.
# چکلیست امنیت OAuth 2.0
قبل از Production این موارد را بررسی کنید:
[ ] HTTPS فعال است
[ ] Redirect URI محدود و ثبتشده است
[ ] state بررسی میشود
[ ] برای Public Client از PKCE استفاده شده
[ ] Authorization Code کوتاهعمر است
[ ] Authorization Code یکبار مصرف است
[ ] Access Token Expiration دارد
[ ] Refresh Token امن نگهداری میشود
[ ] Refresh Token Rotation وجود دارد
[ ] Token Revocation وجود دارد
[ ] Scopeها محدود هستند
[ ] Object-Level Authorization بررسی میشود
[ ] Client Secret در Source Code نیست
[ ] Tokenها در Log ثبت نمیشوند
[ ] Rate Limiting وجود دارد
[ ] Errorهای حساس نمایش داده نمیشوند
[ ] تمام Tokenها روی HTTPS منتقل میشوند
# یک معماری پیشنهادی OAuth در PHP
اگر بخواهیم یک سیستم OAuth کامل در PHP بسازیم، معماری میتواند چنین باشد:
User
│
▼
PHP Client
│
▼
Authorization Endpoint
│
Login / Consent
│
▼
Authorization Code
│
▼
Token Endpoint
│
┌────────┴────────┐
▼ ▼
Access Token Refresh Token
│
▼
API Request
│
▼
Resource Server
│
┌─────┴─────┐
▼ ▼
Scope Authorization
│ │
└─────┬─────┘
▼
Resource
# آیا باید OAuth را از صفر بنویسیم؟
از نظر آموزشی، پیادهسازی مفاهیم OAuth در PHP بسیار مفید است.
اما در Production، پیادهسازی کامل یک Authorization Server از صفر کار حساسی است.
چرا؟
چون موارد زیادی باید درست پیادهسازی شوند:
Token Security
PKCE
Redirect Validation
Client Authentication
Scope
Token Rotation
Revocation
Replay Protection
Expiration
Consent
Session Security
Error Handling
یک اشتباه کوچک میتواند روی امنیت تمام Application تأثیر بگذارد.
بنابراین در پروژه واقعی بهتر است از پیادهسازیها و کتابخانههای معتبر و استاندارد استفاده شود، بهجای اینکه کل Protocol از صفر ساخته شود.
# OAuth 2.0 در Laravel
اگر پروژه با Laravel ساخته شده باشد، میتوان معماری OAuth را با ابزارها و Packageهای استاندارد این اکوسیستم پیادهسازی کرد.
برای APIهای ساده User-based ممکن است Laravel Sanctum انتخاب مناسبی باشد.
برای سناریوهای OAuth کامل، معمولاً باید از یک پیادهسازی OAuth 2.0 استاندارد مانند Laravel Passport یا یک Identity Provider تخصصی استفاده کرد؛ انتخاب نهایی به معماری پروژه بستگی دارد.
مهم این است که بین:
Simple API Authentication
و:
Full OAuth Authorization Server
تفاوت قائل شویم.
# جمعبندی
OAuth 2.0 یک Framework مهم برای Authorization است که به Applicationها اجازه میدهد بدون دریافت Password کاربر، دسترسی محدود و کنترلشدهای به Resourceها دریافت کنند.
مهمترین مفاهیمی که در این مقاله بررسی کردیم عبارتاند از:
Resource Owner
Client
Authorization Server
Resource Server
Scope
Authorization Code
Access Token
Refresh Token
PKCE
state
Token Rotation
Token Revocation
همچنین دیدیم که:
OAuth ≠ JWT
OAuth ≠ Session
OAuth ≠ Password Authentication
JWT میتواند یکی از قالبهای Access Token باشد، اما OAuth 2.0 یک چارچوب گستردهتر برای مدیریت Authorization است.
برای Public Clientها نیز استفاده از Authorization Code + PKCE اهمیت ویژهای دارد.
در نهایت، امنیت OAuth فقط به دریافت Token ختم نمیشود؛ باید Expiration، Revocation، Scope، Authorization، Redirect URI، HTTPS، Rate Limiting و مدیریت امن Secretها نیز در معماری لحاظ شوند.
# سوالات متداول
OAuth 2.0 چیست؟
OAuth 2.0 یک Framework برای Authorization است که امکان اعطای دسترسی محدود به Resourceها بدون در اختیار قرار دادن Password کاربر به Client را فراهم میکند.
آیا OAuth همان JWT است؟
خیر. OAuth یک Authorization Framework است و JWT یک Token Format است.
Access Token چیست؟
Access Token مجوزی است که Client برای دسترسی به Resource Server استفاده میکند.
Refresh Token چیست؟
Refresh Token برای دریافت Access Token جدید استفاده میشود و معمولاً عمر بیشتری از Access Token دارد.
PKCE چیست؟
PKCE مکانیزمی برای محافظت از Authorization Code Flow است و برای Public Clientهایی مانند Mobile App و SPA اهمیت زیادی دارد.
آیا OAuth برای API مناسب است؟
بله. OAuth 2.0 برای سناریوهایی که نیاز به Delegated Authorization و کنترل دسترسی Token-based دارند بسیار کاربردی است.
آیا OAuth برای Login استفاده میشود؟
OAuth بهتنهایی یک استاندارد Login نیست. برای Authentication استاندارد معمولاً OpenID Connect روی OAuth 2.0 استفاده میشود.
آیا Access Token باید JWT باشد؟
خیر. Access Token میتواند JWT یا یک Token opaque باشد.
آیا باید OAuth را خودمان در PHP از صفر بنویسیم؟
برای یادگیری بله، اما برای Production بهتر است از پیادهسازیهای استاندارد و معتبر استفاده شود.
# مقاله بعدی
بعد از این مقاله، مسیر منطقی کلاستر میتواند به موضوع:
«OpenID Connect در PHP چیست؟ آموزش Login با OAuth 2.0 و OIDC»
برسد.
در آن مقاله تفاوت دقیق Authentication و Authorization، مفهوم ID Token، UserInfo Endpoint، Identity Provider و پیادهسازی Login با سرویسهایی مانند Google و سایر Identity Providerها را بررسی خواهیم کرد.
