چرا انتخاب بین OAuth و JWT اغلب به جای حل مسئله، مشکل جدیدی می‌سازد؟

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

چرا سؤال «OAuth یا JWT» از ابتدا اشتباه است؟

پرسش «OAuth یا JWT؟» شبیه این است که بپرسید «ماشین یا بنزین؟». یکی وسیله نقلیه است و دیگری سوخت. OAuth یک پروتکل (Protocol) احراز هویت و مجوزدهی است؛ JWT یک فرمت توکن (Token) است. این دو، در لایه‌های مختلف معماری نرم‌افزار زندگی می‌کنند و در بسیاری از پیاده‌سازی‌های مدرن، با هم ترکیب می‌شوند. اما چون هر دو با مفهوم authentication و authorization سر و کار دارند، در ذهن بسیاری از توسعه‌دهندگان با هم قاطی می‌شوند.

متأسفانه این اشتباه پایه‌ای، در مستندات بسیاری از سرویس‌ها و حتی بعضی منابع آموزشی، تقویت می‌شود. من در پروژه‌های واقعی دیده‌ام که تیم‌ها سعی می‌کنند یکی از این دو را انتخاب کنند و دیگری را کنار بگذارند، در حالی که مسئله اصلی این نیست. اگر با مفاهیم پایه‌ای احراز هویت و مجوزدهی آشنایی کمتری دارید، پیشنهاد می‌کنم ابتدا مقاله احراز هویت چیست و چه انواعی دارد را بخوانید تا بستر مقایسه روشن شود.

مقایسه OAuth با JWT مثل مقایسه HTTP با JSON است؛ یکی پروتکل است، دیگری فرمت. تفاوت این دو، تفاوت بستر و محتواست.

پرسش درست این است: در پروژه من، مسئله اصلی کدام است؟ اگر مسئله من این است که یک برنامه ثالث باید به بخشی از داده‌های کاربران من دسترسی داشته باشد، پاسخ OAuth است. اگر مسئله من این است که بعد از ورود کاربر، درخواست‌های بعدی او را چطور تأیید کنم، پاسخ ممکن است JWT یا session باشد. تشخیص درست مسئله، نیمی از تصمیم‌گیری است. اگر با اصول تصمیم‌گیری معماری آشنا نیستید، مقالات مربوط به اصول طراحی معماری وب مدرن دیدگاه مکملی ارائه می‌دهد.

OAuth دقیقاً چیست و چه مسئله‌ای را حل می‌کند؟

OAuth که مخفف Open Authorization است، یک استاندارد باز برای دسترسی تفویض‌شده (Delegated Access) است. یعنی کاربر به یک برنامه ثالث اجازه می‌دهد به‌جای او به بخشی از منابع سرورش دسترسی داشته باشد، بدون اینکه رمز عبور خودش را در اختیار آن برنامه بگذارد. این مفهوم، اولین بار در سال ۲۰۰۶ با OAuth 1.0 مطرح شد و امروز OAuth 2.0 استاندارد غالب است. نسخه OAuth 2.1 هم در حال تثبیت است که بعضی الگوهای ناامن نسخه قبل را حذف می‌کند.

مفاهیم کلیدی در OAuth

برای درک درست OAuth، چهار مفهوم کلیدی باید در ذهن شما شفاف باشند:

سناریوی کلاسیک OAuth این است: کاربر روی دکمه «ورود با گوگل» کلیک می‌کند. برنامه شما (Client) کاربر را به Authorization Server گوگل هدایت می‌کند. کاربر آن‌جا وارد حساب گوگل خود می‌شود و به برنامه شما اجازه دسترسی به بخش مشخصی از داده‌هایش (مثلاً ایمیل و نام) را می‌دهد. گوگل سپس یک Authorization Code به برنامه شما برمی‌گرداند که آن را با Access Token عوض می‌کند. این Access Token، کلید دسترسی به داده‌های کاربر است.

چهار فلو اصلی OAuth 2.0

OAuth 2.0 چهار فلو اصلی دارد که هر کدام برای سناریوی خاصی طراحی شده‌اند:

• Authorization Code: مناسب برنامه‌های وب سمت سرور. امن‌ترین فلو.
• Authorization Code with PKCE: مناسب اپلیکیشن‌های موبایل و SPA. در OAuth 2.1 توصیه اصلی است.
• Client Credentials: مناسب ارتباط سرویس به سرویس، بدون دخالت کاربر.
• Device Code: مناسب دستگاه‌های بدون مرورگر مثل تلویزیون هوشمند.

دو فلو Implicit و Resource Owner Password Credentials که در OAuth 2.0 بودند، در OAuth 2.1 کنار گذاشته شده‌اند چون از نظر امنیتی ضعف‌های جدی داشتند. اگر با نسخه‌های قدیمی‌تر آشنا هستید، این تغییر اهمیت جدی دارد. اگر با مفهوم API و نقش آن در معماری آشنا نیستید، مقاله API چیست و چه کاربردی دارد نقطه شروع مناسبی است.

JWT دقیقاً چیست و چه مسئله‌ای را حل می‌کند؟

JWT که مخفف JSON Web Token است، یک فرمت توکن خودکفا (Self-contained Token) است که اطلاعات را به‌شکل امضاشده در خودش حمل می‌کند. هر JWT از سه بخش تشکیل شده که با نقطه از هم جدا می‌شوند: Header، Payload و Signature. این سه بخش، به‌ترتیب با Base64Url کدگذاری شده‌اند.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

اجزای JWT

هر JWT، سه بخش اصلی دارد:

• Header: شامل الگوریتم امضا (Signature Algorithm) و نوع توکن. مثلاً HS256 یا RS256.
• Payload: شامل Claims یا اظهارات درباره کاربر. سه دسته Claim وجود دارد: Registered Claims (مثل sub، exp، iat)، Public Claims، و Private Claims.
• Signature: امضای دیجیتال که صحت توکن را تأیید می‌کند. با کلید مخفی (در HS256) یا کلید خصوصی (در RS256) محاسبه می‌شود.

ویژگی‌های مهم JWT

JWT سه ویژگی دارد که آن را برای سناریوهای خاصی ایده‌آل می‌کند:

• Stateless بودن: سرور نیازی به ذخیره توکن ندارد. تأیید JWT با بررسی امضا انجام می‌شود.
• خودکفا بودن: همه اطلاعات لازم در خود توکن است، بدون نیاز به کوئری به دیتابیس.
• قابل حمل بودن: JWT در هر زبانی و پلتفرمی می‌تواند خوانده شود.

این سه ویژگی در پروژه‌های microservices و stateless APIها، مزیت جدی هستند. اما همین ویژگی‌ها، در پروژه‌های دیگر می‌توانند نقطه ضعف باشند. مثلاً Stateless بودن یعنی نمی‌توانید یک توکن را قبل از انقضا باطل کنید. اگر با مفاهیم معماری microservices آشنا نیستید، معماری مونولیتیک یا میکروسرویس چارچوب کاملی ارائه می‌دهد.

JWT و خانواده JOSE

JWT بخشی از یک خانواده استانداردهای بزرگ‌تر به نام JOSE (JavaScript Object Signing and Encryption) است. این خانواده شامل JWS (امضا)، JWE (رمزنگاری)، JWK (کلیدها) و JWA (الگوریتم‌ها) می‌شود. درک این خانواده، در پروژه‌های امنیتی جدی کمک می‌کند، چون خیلی از مسائل امنیتی JWT، ریشه در انتخاب اشتباه JOSE یا مدیریت نادرست کلیدها دارد.

تفاوت بنیادین OAuth و JWT در یک نگاه

حالا با درک هر دو، می‌توانیم تفاوت بنیادین را در یک جدول جمع کنیم:

با نگاه به این جدول، روشن می‌شود که این دو، در واقع مکمل یکدیگرند. OAuth اغلب از JWT به‌عنوان فرمت توکنش استفاده می‌کند. یعنی «OAuth با JWT» یک ترکیب بسیار رایج است که در آن، OAuth فرآیند احراز هویت را مدیریت می‌کند و JWT فرمت توکن نهایی است.

در پروژه‌های مدرن، سؤال درست این نیست که «OAuth یا JWT؟». سؤال درست این است که «در این پروژه، کدام الگوی ترکیبی از این دو، مسئله من را حل می‌کند؟»

الگوی ترکیبی: OAuth + JWT در پروژه‌های واقعی

در تجربه‌ام، بیشترین سردرگمی توسعه‌دهندگان از این ناشی می‌شود که فکر می‌کنند باید یکی را انتخاب کنند. اما در معماری مدرن، این دو به‌طور طبیعی با هم ترکیب می‌شوند. یک الگوی رایج که در پروژه‌های خودم زیاد استفاده کرده‌ام:

معماری Authorization Server + JWT

در این الگو، شما یک Authorization Server جدا دارید که با OAuth کار می‌کند. این سرور مسئول احراز هویت کاربر و صدور توکن است. توکن صادر شده، یک JWT است که شامل Claims مربوط به کاربر و مجوزهایش است. Resource Server شما، درخواست‌های API را با verification کردن JWT تأیید می‌کند.

۱. کاربر به Client وارد می‌شود
۲. Client کاربر را به Authorization Server هدایت می‌کند
۳. کاربر احراز هویت می‌شود
۴. Authorization Server یک JWT صادر می‌کند
۵. Client این JWT را در درخواست‌های API ارسال می‌کند
۶. Resource Server، JWT را verify می‌کند (بدون کوئری به دیتابیس)
۷. Resource Server درخواست را پاسخ می‌دهد

این الگو، هم مزیت OAuth را دارد (احراز هویت متمرکز، استاندارد، پشتیبانی از SSO) و هم مزیت JWT را (Stateless بودن، مقیاس‌پذیری بالا). در تجربه‌ام، این الگو در پروژه‌های microservices و SaaS بهترین جواب را داده است.

اگر با مفاهیم SSO آشنا نیستید، مقاله SSO چطور تجربه کاربری سازمانی را متحول می‌کند چارچوب کاملی ارائه می‌دهد. ترکیب OAuth، JWT و SSO، استخوان‌بندی معماری احراز هویت پروژه‌های سازمانی مدرن را می‌سازد.

چه زمانی OAuth تنها کافی است؟

در بعضی سناریوها، JWT در تصویر مسئله حضور ندارد و OAuth به‌تنهایی پاسخ می‌دهد. سه سناریو که در تجربه‌ام زیاد دیده‌ام:

دسترسی برنامه ثالث به داده کاربر

اگر پروژه شما به کاربران اجازه می‌دهد به برنامه‌های ثالث دسترسی بدهند (مثل یک افزونه که به حساب گوگل کاربر متصل می‌شود)، OAuth 2.0 با Access Token کافی است. نیازی نیست حتماً JWT در تصویر باشد. توکن‌های OAuth می‌توانند opaque باشند و در دیتابیس ذخیره شوند.

ورود با شبکه‌های اجتماعی

سناریوی کلاسیک «ورود با گوگل» یا «ورود با گیت‌هاب». در این حالت، OAuth فرآیند را مدیریت می‌کند و برنامه شما معمولاً یک session داخلی می‌سازد. JWT در این سناریو، الزاماً نقش اساسی ندارد.

SSO سازمانی

در سازمان‌هایی که از SSO استفاده می‌کنند، OAuth یا OpenID Connect (که لایه احراز هویت روی OAuth است) معمولاً با SAML یا سایر پروتکل‌ها ترکیب می‌شود. JWT ممکن است در بعضی جاها حضور داشته باشد، اما انتخاب اصلی نیست. برای درک عمیق‌تر OpenID Connect، مراجعه به مستندات رسمی این استاندارد مفید است.

چه زمانی JWT تنها کافی است؟

در مقابل، سناریوهایی وجود دارند که OAuth لازم نیست و JWT به‌تنهایی مسئله را حل می‌کند:

اپلیکیشن‌های تک‌صفحه‌ای (SPA)

برای یک SPA که فقط با API خودش کار می‌کند و نیازی به دسترسی برنامه ثالث ندارد، JWT می‌تواند به‌تنهایی کافی باشد. کاربر با username و password وارد می‌شود، سرور یک JWT صادر می‌کند و درخواست‌های بعدی با همان JWT تأیید می‌شوند. اما همین‌جا یک هشدار جدی دارم: در SPAها، ذخیره JWT در localStorage یک ریسک جدی XSS است. روش‌های امن‌تر (مثل کوکی‌های HttpOnly) در ادامه توضیح داده می‌شوند.

ارتباط سرویس به سرویس

در معماری microservices، ارتباط بین سرویس‌ها اغلب با JWT انجام می‌شود. هر سرویس با یک JWT که امضا شده توسط یک کلید مشترک یا کلید خصوصی، درخواست‌هایش را به سرویس دیگر می‌فرستد. در این حالت، OAuth در تصویر نیست چون کاربر نهایی دخالت ندارد.

API موبایل

برای اپلیکیشن موبایل که به API بک‌اند خودش وصل می‌شود، JWT با refresh token می‌تواند الگوی کافی باشد. استفاده از OAuth در این حالت، پیچیدگی اضافه‌ای ایجاد می‌کند که در پروژه‌های کوچک و متوسط توجیه‌پذیر نیست.

پروژه‌های Stateless با مقیاس بالا

اگر پروژه شما در چند سرور پخش شده و نمی‌خواهید بین سرورها session را sync کنید، JWT ابزار طبیعی است. اما توجه کنید: در این الگو، مسئله ابطال توکن قبل از انقضا یک چالش جدی می‌شود که باید راه‌حل داشته باشید.

JWT در برابر Session: مقایسه‌ای که واقعاً مهم است

پرسش واقعی که در پروژه‌ها باید بپرسید، این است: JWT یا Session؟ نه OAuth یا JWT. این دو، دو رویکرد کاملاً متفاوت برای مدیریت احراز هویت هستند و هر کدام نقطه قوت و ضعف مشخصی دارند.

در تجربه‌ام، برای بیشتر پروژه‌های وردپرسی و اپلیکیشن‌های Monolithic، Session انتخاب درست‌تری است. چرا؟ چون سادگی و ابطال فوری، در این سناریوها مزیت بزرگ‌تری هستند از مقیاس‌پذیری توزیع‌شده. اما در معماری microservices یا APIهایی که چند سرویس مختلف باید به‌طور هم‌زمان احراز هویت را تأیید کنند، JWT مزیت جدی می‌شود.

یک دام رایج: در SPAها که از JWT استفاده می‌شود و JWT در localStorage ذخیره می‌شود، XSS (Cross-Site Scripting - تزریق اسکریپت سمت کاربر) می‌تواند به دزدیدن توکن منجر شود. راه‌حل امن‌تر، ذخیره JWT در کوکی HttpOnly و تنظیم CSRF token جداگانه است. اصول کامل این حوزه در حملات XSS چیست و چگونه دفع می‌شود و CSRF چیست و چگونه از آن جلوگیری کنیم آمده است.

در انتخاب بین Session و JWT، تصمیم درست معمولاً از جنس معماری است، نه از جنس مد روز. آن‌چه در پروژه‌های کوچک بهترین است، در پروژه‌های بزرگ الزاماً بهترین نیست.

دام‌های امنیتی که پروژه را نابود می‌کند

در بازبینی ده‌ها پیاده‌سازی OAuth و JWT، دام‌های امنیتی تکراری دیده‌ام که هرکدام می‌تواند امنیت کل پروژه را از بین ببرد.

الگوریتم none در JWT

یکی از معروف‌ترین حملات JWT، استفاده از الگوریتم none است. بعضی کتابخانه‌های قدیمی اگر در Header توکن، الگوریتم none دیده شود، امضا را نادیده می‌گیرند. مهاجم می‌تواند این را دستکاری کند و توکن جعلی بسازد. راه‌حل: همیشه در verify توکن، الگوریتم را صریحاً مشخص کنید و از الگوریتم‌های ضعیف (مثل HS256 با کلید کوتاه) خودداری کنید.

کلید مخفی ضعیف یا مشترک

در JWT با HS256، امنیت به کلید مخفی وابسته است. اگر کلید کوتاه یا قابل حدس باشد، مهاجم می‌تواند توکن جعلی بسازد. اگر کلید بین چند پروژه مشترک باشد و یکی از آن‌ها لورود شود، همه پروژه‌ها آسیب‌پذیر می‌شوند. تجربه‌ام: کلید باید حداقل ۲۵۶ بیت آنتروپی داشته باشد و از یک Secret Manager خوانده شود، نه از یک فایل configuration ثابت.

نبود زمان انقضا

JWT بدون فیلد exp، عملاً یک بلیط دائمی است. اگر این توکن دزدیده شود، مهاجم تا ابد به حساب کاربر دسترسی دارد. راه‌حل: زمان انقضای کوتاه برای Access Token (۱۵ دقیقه تا یک ساعت) و استفاده از Refresh Token برای تمدید. اصول این الگو در چگونه نشست‌های کاربری را امن کنیم آمده است.

قرار دادن توکن در URL

اگر توکن را به‌عنوان query parameter در URL قرار دهید، در لاگ سرور، در Referrer Header و در مرورگر کاربر ذخیره می‌شود. این یک ریسک جدی است. توکن باید همیشه در Authorization Header یا در کوکی HttpOnly قرار گیرد.

تنظیم نادرست Redirect URI در OAuth

در OAuth، اگر Redirect URI به‌طور دقیق (Exact Match) تنظیم نشود، مهاجم می‌تواند کاربر را به یک دامنه جعلی هدایت کند و Authorization Code را بدزدد. این حمله در پروژه‌های واقعی زیاد دیده می‌شود. راه‌حل: همیشه Redirect URI را به‌طور کامل و دقیق در Authorization Server ثبت کنید و از Wildcard استفاده نکنید.

استفاده از Implicit Flow

Implicit Flow که در OAuth 2.0 بود، به‌خاطر ضعف‌های امنیتی جدی در OAuth 2.1 حذف شده. این فلو توکن را در URL Fragment برمی‌گرداند که هم از نظر لاگ و هم از نظر XSS آسیب‌پذیر است. جایگزین درست: Authorization Code with PKCE.

نادیده گرفتن PKCE در موبایل و SPA

PKCE (Proof Key for Code Exchange) یک لایه امنیتی است که برای جلوگیری از حملات Authorization Code Interception اضافه شده. در اپلیکیشن‌های موبایل و SPAها که Client Secret نمی‌تواند به‌طور امن نگهداری شود، PKCE ضروری است. تجربه‌ام: در چند پروژه که PKCE در ابتدا نادیده گرفته شده بود، بعداً افزودنش چالش‌های جدی داشت. از همان ابتدا PKCE را فعال کنید.

نادیده گرفتن چرخش Refresh Token

Refresh Token که به‌عنوان بلیط بلندمدت برای تمدید Access Token استفاده می‌شود، باید با هر بار استفاده، تازه (Rotate) شود. اگر Refresh Token ثابت بماند، دزدیدن آن معادل دزدیدن دسترسی دائمی است. مفهوم Refresh Token Rotation، در حال حاضر بخش استاندارد پیاده‌سازی‌های مدرن OAuth است.

OAuth و JWT در پروژه‌های وردپرسی

وردپرس، به‌طور تاریخی از Cookie-based Authentication استفاده می‌کند. اما در سال‌های اخیر، استفاده از JWT در پروژه‌های وردپرسی به‌طور جدی رشد کرده، خصوصاً در پروژه‌های Headless و اپلیکیشن‌های موبایل متصل به وردپرس. اگر با مفاهیم پایه وردپرس آشنا نیستید، وردپرس چیست و چگونه شروع به کار با آن کنیم نقطه شروع است.

JWT در WordPress REST API

وردپرس یک REST API (Representational State Transfer Application Programming Interface) دارد که در هسته پشتیبانی می‌شود. برای احراز هویت در این API، سه روش اصلی وجود دارد:

• Cookie Authentication: روش پیش‌فرض، مناسب برای درخواست‌های داخل خود سایت.
• Application Passwords: روش استاندارد وردپرس که از نسخه ۵.۶ اضافه شده و امن‌ترین گزینه برای APIهای خارجی است.
• JWT Authentication: از طریق افزونه‌های شخص ثالث. انعطاف بیشتر اما مسئولیت امنیتی بیشتر.

نکته مهم: قبل از راه‌اندازی JWT در وردپرس، حتماً Article API در وردپرس را بخوانید تا بستر فنی روشن باشد.

OAuth در وردپرس

OAuth در وردپرس کاربرد جدی دارد، خصوصاً در سناریوهایی مثل اتصال به Google Analytics یا Google Search Console از داخل پنل وردپرس. افزونه‌های مختلف این اتصال را با OAuth پیاده‌سازی می‌کنند. اگر با فرآیند اتصال به Google Search Console آشنایی کمتری دارید، مطالب مرتبط با آن در سایت موجود است.

وردپرس Headless

در معماری Headless که در آن Frontend (مثلاً با Next.js) از Backend (وردپرس) جدا می‌شود، JWT نقش جدی پیدا می‌کند. معماری توصیه‌شده: Frontend با JWT احراز هویت می‌کند، Backend وردپرس با verify کردن JWT پاسخ می‌دهد. اگر با Next.js آشنایی کمتری دارید، بهترین Boilerplateهای React نقطه شروع خوبی است.

املاحظات امنیتی خاص وردپرس

سه نکته امنیتی که در پروژه‌های وردپرسی با JWT زیاد دیده‌ام:

1. غیرفعال کردن REST API برای کاربران مهمان: اگر نیازی به دسترسی عمومی به API نیست، مسیرهای sensitive را مسدود کنید.
2. استفاده از HTTPS: JWT در ترافیک HTTP، عملاً یک متن باز است. HTTPS اجبار است. اگر با تفاوت HTTP و HTTPS آشنایی کمتری دارید، HTTPS چیست و چه تفاوتی با HTTP دارد را ببینید.
3. مدیریت درست کلیدها: کلید JWT وردپرس باید در متغیر محیطی یا Secret Manager نگهداری شود، نه در فایل wp-config.php با متن ساده. اگر با امنیت wp-config آشنا نیستید، چگونه فایل wp-config را امن کنیم راهنمای کاملی است.

پرسش‌های پرتکرار درباره انتخاب OAuth و JWT

مهم‌ترین تفاوت OAuth و JWT در یک جمله چیست؟

OAuth یک پروتکل برای دسترسی تفویض‌شده است؛ JWT یک فرمت توکن برای حمل امن اطلاعات. یکی فرآیند است، دیگری ساختار. در بیشتر پیاده‌سازی‌های مدرن، OAuth از JWT به‌عنوان فرمت توکنش استفاده می‌کند و این دو مکمل یکدیگرند، نه جانشین.

برای پروژه من کدام را انتخاب کنم؟

پاسخ در گرو مسئله شماست. اگر مسئله دسترسی برنامه ثالث به داده کاربران است، OAuth. اگر مسئله احراز هویت Stateless برای APIهای خودتان است، JWT. اگر پروژه شما به هر دو نیاز دارد (مثل SaaS که هم از ورود با گوگل پشتیبانی می‌کند و هم API خودش را دارد)، الگوی ترکیبی Authorization Server با JWT پاسخ درست است.

برای اپلیکیشن وب ساده، JWT یا Session؟

برای بیشتر اپلیکیشن‌های وب Monolithic، Session انتخاب درست‌تری است. سادگی و ابطال فوری، در این سناریوها مهم‌تر از مقیاس‌پذیری توزیع‌شده هستند. اگر پروژه شما روی یک سرور اجرا می‌شود یا از Load Balancer با Sticky Session استفاده می‌کند، Session به‌طور جدی ساده‌تر است.

در SPA، JWT را کجا ذخیره کنم؟

کوتاه‌ترین پاسخ: در کوکی HttpOnly با SameSite=Strict و Secure. این ترکیب، هم از XSS محافظت می‌کند و هم از CSRF. اما برای محافظت کامل از CSRF، بهتر است علاوه بر کوکی، یک CSRF token جداگانه هم ارسال شود. ذخیره JWT در localStorage، به‌خاطر آسیب‌پذیری در برابر XSS، توصیه نمی‌شود.

چطور JWT را قبل از انقضا باطل کنم؟

چون JWT ذاتاً Stateless است، باطل کردن فوری آن نیازمند یک لایه اضافه است. سه راه‌حل: اول، Blacklist کردن توکن در Redis یا دیتابیس (سریع‌ترین اما Stateful). دوم، نگهداری نسخه کلیدها (Key Rotation) و باطل کردن همه توکن‌های قدیمی هنگام تغییر. سوم، استفاده از Access Token کوتاه‌مدت (۱۵ دقیقه) و Refresh Token طولانی‌مدت که قابل باطل کردن است. در پروژه‌های خودم، ترکیب راه‌حل اول و سوم بهترین نتیجه را داده.

چرا Implicit Flow در OAuth منسوخ شده؟

Implicit Flow توکن را مستقیماً در URL Fragment برمی‌گرداند. این سه مشکل جدی دارد: توکن در لاگ سرور ذخیره می‌شود، در Referrer Header ارسال می‌شود و از طریق XSS قابل سرقت است. Authorization Code with PKCE، جایگزین امن‌تری است که همین قابلیت را با محافظت بیشتر ارائه می‌دهد.

آیا اندازه بزرگ JWT مشکل‌ساز است؟

JWT بزرگ، در هر درخواست ارسال می‌شود و حجم ترافیک را زیاد می‌کند. در پروژه‌هایی که Claims زیادی در JWT قرار می‌گیرد، این مسئله محسوس می‌شود. توصیه: در JWT فقط شناسه کاربر و مجوزهای ضروری را قرار دهید، بقیه اطلاعات را در سمت سرور نگه دارید.

تفاوت OAuth با OpenID Connect چیست؟

OpenID Connect (OIDC) یک لایه احراز هویت روی OAuth 2.0 است. OAuth برای مجوزدهی (Authorization) طراحی شده، اما برای احراز هویت (Authentication) استاندارد مشخصی نداشت. OIDC این شکاف را با اضافه کردن ID Token (که خودش یک JWT است) و endpointهای استاندارد پر می‌کند. اگر می‌خواهید «ورود با گوگل» را پیاده کنید، در واقع OIDC را استفاده می‌کنید، نه فقط OAuth.

آیا JWT هزینه پردازشی دارد؟

بله، اما ناچیز. Verify کردن JWT با الگوریتم HS256، در حد میکروثانیه طول می‌کشد. با RS256 که از رمزنگاری کلید عمومی استفاده می‌کند، کمی کندتر است اما همچنان سریع. تفاوت واقعی در این است که JWT نیازی به کوئری دیتابیس ندارد، که در پروژه‌های پربازدید، مزیت جدی محسوب می‌شود. اگر با فرآیند بهینه‌سازی دیتابیس آشنا نیستید، تاثیر دیتابیس بر سرعت سایت چقدر است تحلیل کاملی ارائه می‌دهد.

پروژه‌های بزرگ دنیا از کدام استفاده می‌کنند؟

پروژه‌های بزرگ معمولاً الگوی ترکیبی را انتخاب می‌کنند. گوگل، مایکروسافت و آمازون، همگی Authorization Server دارند که OAuth 2.0 را پیاده می‌کند و از JWT (یا فرمت مشابه) به‌عنوان توکن استفاده می‌کند. این رویکرد، هم استاندارد است و هم مقیاس‌پذیر. در پروژه‌های متوسط، پیاده‌سازی کامل این الگو ممکن است بیش از حد پیچیده باشد، اما درک آن، دیدگاه معماری درستی به شما می‌دهد.

آن‌چه سال‌ها بعد در معماری پروژه می‌ماند

پس از سال‌ها کار با پروژه‌های مختلف، به یک نتیجه‌گیری ساده رسیده‌ام: انتخاب بین OAuth و JWT، در واقع انتخاب بین دو لایه مختلف معماری است. اگر این دو را در جای درست خودشان قرار دهید، نه‌فقط با هم تناقض ندارند، بلکه یکدیگر را تقویت می‌کنند. اگر آن‌ها را در جای اشتباه قرار دهید، هر کدام به‌تنهایی هم می‌تواند مشکل‌ساز شود.

در تجربه‌ام، تیم‌هایی که این تفکیک را در ذهن ندارند، معمولاً چند سال بعد با یک معماری احراز هویت پیچیده و شکست‌خورده مواجه می‌شوند که هم امنیت کافی ندارد و هم نگهداری‌اش دشوار است. تیم‌هایی که از ابتدا این تفکیک را رعایت می‌کنند، معماری احراز هویت‌شان با رشد پروژه، طبیعی رشد می‌کند.

توصیه نهایی من: قبل از هر تصمیمی، سه سؤال از خودتان بپرسید. اول، در پروژه من چه کسی صاحب داده است؟ دوم، چه کسی باید به این داده دسترسی داشته باشد؟ سوم، این دسترسی چقدر باید طول بکشد؟ پاسخ این سه سؤال، به‌طور طبیعی نقشه تصمیم‌گیری را روشن می‌کند. هیچ قالبی برای همه پروژه‌ها وجود ندارد؛ آن‌چه وجود دارد، تشخیص درست مسئله است.

اگر تجربه‌ای از پیاده‌سازی OAuth یا JWT در پروژه‌های واقعی دارید — به‌خصوص اگر با دام‌های امنیتی یا پیچیدگی‌های ترکیبی مواجه شده‌اید که در این مقاله جا مانده — در دیدگاه‌ها بنویسید. این تجربه‌های میدانی، برای توسعه‌دهنده بعدی که این مسیر را شروع می‌کند، از هر مستند رسمی ارزشمندترند. 🔐