معرفی کامل OAuth 2.1 و تفاوت آن با OAuth 2.0 در سال ۲۰۲۵

OAuth 2.1 نسل جدید و استانداردسازی‌شده نسخه OAuth 2.0 است که با هدف افزایش امنیت، حذف روش‌های قدیمی و ساده‌سازی جریان احراز هویت ایجاد شده است. استاندارد OAuth 2.0 به دلیل انعطاف‌پذیری بالا، در سال‌های گذشته باعث ایجاد پیاده‌سازی‌های ناامن و سردرگمی توسعه‌دهندگان شده بود، اما OAuth 2.1 همه بهترین روش‌های امنیتی را یکجا جمع کرده و نسخه‌ای مدرن، امن و قابل اطمینان ارائه می‌دهد.

OAuth چیست و چرا ایجاد شد؟

OAuth به‌طور کلی یک پروتکل مجوزدهی (Authorization) است و برای احراز هویت (Authentication) ایجاد نشده است؛ اما بسیاری از سیستم‌ها از آن به عنوان روش ورود (Login) نیز استفاده می‌کنند.

هدف OAuth این است که به کاربر اجازه دهد بدون دادن رمز عبور به سرویس ثالث، به اطلاعات محدود و مشخصی در سرویس اصلی دسترسی دهد. برای مثال، ورود به یک وب‌سایت با حساب گوگل یا گیت‌هاب.

چرا OAuth 2.1 معرفی شد؟

چند دلیل مهم وجود داشت که باعث شد OAuth 2.1 شکل بگیرد:

• وجود چندین جریان ناامن در OAuth 2.0 مانند Implicit Flow
• ابهام و پیچیدگی زیاد که منجر به پیاده‌سازی‌های اشتباه می‌شد
• عدم استفاده خودکار توسعه‌دهندگان از PKCE
• مشکلات امنیتی در Single Page Apps
• نیاز به استاندارد واحد برای موبایل و وب

OAuth 2.1 همه این ضعف‌ها را هدف گرفته و نسخه‌ای استانداردتر و امن‌تر ارائه کرده است.

تفاوت‌های کلیدی OAuth 2.0 و OAuth 2.1

جریان‌های حذف شده در OAuth 2.1

۱. حذف کامل Implicit Flow

این جریان به دلیل ارسال توکن در URL و نبود قابلیت تأیید توکن، از نظر امنیتی خطرناک شناخته شد و کاملاً حذف شده است.

۲. حذف Password Grant

در این روش، کاربر رمز عبور خود را مستقیم به برنامه می‌داد! این روش بیشترین نشت رمز عبور را در پروژه‌های قدیمی ایجاد می‌کرد و دیگر مجاز نیست.

۳. Resource Owner Credentials

مشابه Password Grant و به دلایل امنیتی حذف شده است.

OAuth 2.1 چه چیزهایی را اجباری کرده است؟

۱. اجباری شدن PKCE

PKCE در ابتدا برای اپلیکیشن‌های موبایل معرفی شد اما اکنون برای همه انواع برنامه‌ها، از جمله Backend + SPA اجباری است.

۲. استفاده از HTTPS

دیگر هیچ پیاده‌سازی بدون HTTPS مجاز نیست.

۳. استفاده از SameSite Cookies

برای جلوگیری از حملات CSRF الزامی شده است.

ساختار Authorization Code Flow در OAuth 2.1

جریان استاندارد و امن تنها از این روش استفاده می‌کند:

1. اپلیکیشن کاربر را به Authorization Server هدایت می‌کند.
2. کاربر احراز هویت می‌شود.
3. Authorization Server کد موقت (Code) برمی‌گرداند.
4. اپلیکیشن با استفاده از PKCE، کد را به توکن تبدیل می‌کند.
5. توکن دسترسی و توکن رفرش دریافت می‌شود.

نمونه کد کامل درخواست توکن با PKCE

۱. تولید Code Verifier و Challenge

// Generate Code Verifier
const verifier = generateRandomString(64);

// Create Challenge
const challenge = base64URLEncode(sha256(verifier));

۲. ارسال درخواست

https://auth.example.com/authorize?
response_type=code
&client_id=your-client-id
&redirect_uri=https://yourapp.com/callback
&code_challenge=${challenge}
&code_challenge_method=S256

۳. تبادل کد برای توکن

POST /token
{
  "grant_type": "authorization_code",
  "code": "xyz",
  "redirect_uri": "...",
  "code_verifier": verifier
}

بهترین روش‌های امنیتی در OAuth 2.1

• استفاده از توکن‌های کوتاه‌عمر
• استفاده از رفرش توکن با Rotation
• ذخیره نکردن توکن در LocalStorage
• استفاده از HttpOnly Cookie
• حذف کامل Implicit Flow
• فعال‌سازی TLS 1.3

OAuth 2.1 برای چه کسانی مناسب است؟

• برنامه‌نویسان بک‌اند
• سرویس‌های ابری (Cloud Providers)
• اپلیکیشن‌های SPA و موبایل
• APIهای مبتنی بر میکروسرویس

سوالات متداول (FAQ)

آیا OAuth 2.1 نسخه کاملاً جدید است؟

نه — درواقع یک مستند واحد از بهترین روش‌های OAuth 2.0 است.

آیا OAuth 2.0 منسوخ شده است؟

نه، اما استفاده از 2.1 توصیه می‌شود و استانداردهای 2.0 به‌تدریج حذف می‌شوند.

آیا Implicit Flow دیگر قابل استفاده است؟

خیر. کاملاً حذف شده است.

آیا برای SPA باید PKCE استفاده شود؟

بله، بدون PKCE پیاده‌سازی امن نیست.

جمع‌بندی

OAuth 2.1 یک نسخه مدرن، ساده‌تر و بسیار امن‌تر از OAuth 2.0 است. این استاندارد با حذف روش‌های ناامن، اجباری‌کردن PKCE و یکسان‌سازی روش‌های پیاده‌سازی، توانسته امنیت سیستم‌های مبتنی بر احراز هویت و مجوزدهی را در سال ۲۰۲۵ ارتقا دهد.

اگر قصد ساخت یک API امن، سرویس ورود یکپارچه یا سیستم OAuth خود را دارید، OAuth 2.1 بهترین انتخاب فعلی است.