
OAuth 2.1 نسخه بهبودیافته و امنتر OAuth 2.0 است که با حذف جریانهای ناامن مانند Implicit Flow، اجباریکردن PKCE، حذف استفاده از Password Grant و یکپارچهسازی بهترین روشهای امنیتی، استاندارد جدیدی برای احراز هویت و مجوزدهی در وب معرفی میکند. این مقاله معماری OAuth 2.1، تفاوت آن با OAuth 2.0، نحوه پیادهسازی در وباپلیکیشنها، توصیههای امنیتی و مثالهای عملی را بهصورت کامل بررسی میکند.
OAuth 2.1 نسل جدید و استانداردسازیشده نسخه OAuth 2.0 است که با هدف افزایش امنیت، حذف روشهای قدیمی و سادهسازی جریان احراز هویت ایجاد شده است. استاندارد OAuth 2.0 به دلیل انعطافپذیری بالا، در سالهای گذشته باعث ایجاد پیادهسازیهای ناامن و سردرگمی توسعهدهندگان شده بود، اما OAuth 2.1 همه بهترین روشهای امنیتی را یکجا جمع کرده و نسخهای مدرن، امن و قابل اطمینان ارائه میدهد.
OAuth بهطور کلی یک پروتکل مجوزدهی (Authorization) است و برای احراز هویت (Authentication) ایجاد نشده است؛ اما بسیاری از سیستمها از آن به عنوان روش ورود (Login) نیز استفاده میکنند.
هدف OAuth این است که به کاربر اجازه دهد بدون دادن رمز عبور به سرویس ثالث، به اطلاعات محدود و مشخصی در سرویس اصلی دسترسی دهد. برای مثال، ورود به یک وبسایت با حساب گوگل یا گیتهاب.
چند دلیل مهم وجود داشت که باعث شد OAuth 2.1 شکل بگیرد:
OAuth 2.1 همه این ضعفها را هدف گرفته و نسخهای استانداردتر و امنتر ارائه کرده است.
| ویژگی | OAuth 2.0 | OAuth 2.1 |
|---|---|---|
| Implicit Flow | وجود دارد (ناامن) | کامل حذف شده |
| Password Grant | پشتیبانی میشود | حذف شده |
| PKCE | اختیاری | اجباری |
| Authorization Code Flow | نسخه قدیمی | نسخه امن با PKCE |
| Security Best Practices | پراکنده و غیرواحد | یکپارچه و دقیق |
| SPA Support | ضعیف و پیچیده | بومی و استاندارد شده |
این جریان به دلیل ارسال توکن در URL و نبود قابلیت تأیید توکن، از نظر امنیتی خطرناک شناخته شد و کاملاً حذف شده است.
در این روش، کاربر رمز عبور خود را مستقیم به برنامه میداد! این روش بیشترین نشت رمز عبور را در پروژههای قدیمی ایجاد میکرد و دیگر مجاز نیست.
مشابه Password Grant و به دلایل امنیتی حذف شده است.
PKCE در ابتدا برای اپلیکیشنهای موبایل معرفی شد اما اکنون برای همه انواع برنامهها، از جمله Backend + SPA اجباری است.
دیگر هیچ پیادهسازی بدون HTTPS مجاز نیست.
برای جلوگیری از حملات CSRF الزامی شده است.
جریان استاندارد و امن تنها از این روش استفاده میکند:
// 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.0 است.
نه، اما استفاده از 2.1 توصیه میشود و استانداردهای 2.0 بهتدریج حذف میشوند.
خیر. کاملاً حذف شده است.
بله، بدون PKCE پیادهسازی امن نیست.
OAuth 2.1 یک نسخه مدرن، سادهتر و بسیار امنتر از OAuth 2.0 است. این استاندارد با حذف روشهای ناامن، اجباریکردن PKCE و یکسانسازی روشهای پیادهسازی، توانسته امنیت سیستمهای مبتنی بر احراز هویت و مجوزدهی را در سال ۲۰۲۵ ارتقا دهد.
اگر قصد ساخت یک API امن، سرویس ورود یکپارچه یا سیستم OAuth خود را دارید، OAuth 2.1 بهترین انتخاب فعلی است.
مقالاتی که ممکن است برای شما جالب باشند
JSON Web Token یا JWT یکی از رایجترین روشهای احراز هویت در معماریهای مدرن وب و موبایل است؛ اما اگر بهدرستی پیادهسازی نشود، میتواند به یکی از بزرگترین نقاط ضعف امنیتی سیستم تبدیل شود. این مقاله در سال ۲۰۲۵، با نگاهی عمیق و بهروز به تهدیدات رایج JWT مانند سرقت توکن، Replay Attack، ضعف در امضا، نگهداری نامناسب در کلاینت، و نشت اطلاعات میپردازد. سپس بهترین روشهای دفاعی از جمله استفاده از Refresh Token Rotation، اعتبار کوتاهمدت توکن، ذخیره امن در HttpOnly Cookie، محدود کردن سطح دسترسی، امضای قدرتمند (HS512/RS256)، استفاده از JTI برای جلوگیری از تکرار و مانیتورینگ رفتار کاربران را بررسی میکند. در نهایت، با ارائه چکلیست عملی برای برنامهنویسان، یک مسیر کامل از تشخیص تهدید تا پیادهسازی معماری احراز هویت ایمن ارائه میشود.