احراز هویت در API راهنمای انتخاب روش درست
چرا انتخاب اشتباه روش احراز هویت در API باعث افشای داده و رخنه امنیتی می‌شود و کدام روش برای هر سناریو مناسبتر است؟
اولین باری که یک API بدون احراز هویت را در پروژه‌ای دیدم، پنل مدیریت داده‌های مشتریان را بدون هیچ توکنی برمی‌گرداند. تیم فکر می‌کرد چون URL را کسی نمی‌داند، امن است. آن روز یاد گرفتم که احراز هویت در API یک افزودنی نیست؛ خط اول دفاع در معماری هر سیستم توزیع‌شده است. اگر تازه با مفاهیم پایه آشنا می‌شوید، API چیست نقطه شروع خوبی است.
چرا احراز هویت API با احراز هویت وب‌سایت فرق دارد؟
در وب‌سایت سنتی، کاربر با مرورگر می‌آید، کوکی می‌گیرد و همان کوکی تا پایان نشست همراه اوست. اما در API، مصرف‌کننده لزوماً مرورگر نیست؛ می‌تواند اپلیکیشن موبایل، سرویس پشت‌صحنه یا اسکریپت زمان‌بندی‌شده باشد. به همین دلیل مکانیزم‌های سنتی مثل Session در API جواب نمی‌دهند یا حداقل بهینه نیستند. برای درک تفاوت‌های معماری، پیشنهاد می‌کنم اصول طراحی REST API را بخوانید.
تفاوت دوم، ماهیت stateless بودن REST است. در REST، هر درخواست باید مستقل باشد و سرور نباید حالت کاربر را نگه دارد. یعنی جایی که در وب از Session استفاده می‌کردیم، در API باید از توکن استفاده کنیم که در هر درخواست همراه بیاید. اگر با اصول REST آشنا نیستید، REST از مفاهیم پایه تا طراحی حرفه‌ای تفاوت‌ها را روشن می‌کند.
احراز هویت API یعنی هر درخواست باید ثابت کند از جانب چه کسی می‌آید و سرور نباید یادش بماند. همین یک جمله، همه تصمیم‌های بعدی را جهت می‌دهد.
چهار روش اصلی احراز هویت در API
در پروژه‌های واقعی، چهار روش اصلی برای احراز هویت API وجود دارد که هرکدام برای سناریوی خاصی مناسب است:
- Basic Authentication: نام کاربری و رمز عبور با Base64 کدگذاری و در هدر ارسال می‌شوند.
- API Key: یک کلید ثابت که در هدر یا Query String ارسال می‌شود.
- JWT (JSON Web Token): توکن امضاشده که اطلاعات کاربر را در خود حمل می‌کند.
- OAuth 2.0: پروتکل احراز هویت توزیع‌شده برای دسترسی تفویضی.
انتخاب بین این چهار روش به ماهیت API، سطح امنیت موردنیاز و نوع مصرف‌کننده بستگی دارد. در ادامه هرکدام را با جزئیات بررسی می‌کنم. برای درک عمیق‌تر JWT و OAuth، JWT چیست و چه کاربردی در احراز هویت دارد و OAuth چیست و چگونه کار می‌کند را ببینید.
Basic Authentication: ساده اما ناکافی
Basic Auth ساده‌ترین روش است: نام کاربری و رمز را با یک دو نقطه ترکیب می‌کنید، Base64 می‌گیرید و در هدر Authorization می‌فرستید. مزیت آن سادگی است؛ در چند خط کد پیاده می‌شود. اما سه ضعف جدی دارد. اول، Base64 رمزنگاری نیست؛ هر کسی که ترافیک را ببیند می‌تواند رمز را بخواند. دوم، در هر درخواست رمز عبور خام ارسال می‌شود. سوم، امکان revoke سریع وجود ندارد.
در پروژه‌ها، Basic Auth را فقط برای محیط‌های تست یا سرویس‌های داخلی که در شبکه محدود هستند توصیه می‌کنم. برای پروژه‌های جدی روش‌های دیگر را انتخاب کنید. برای امنیت بیشتر در مسیر انتقال، راهنمای هدرهای امنیتی HTTP نکات ارزشمندی دارد.
API Key: مناسب سرویس‌های داخلی
API Key یک رشته تصادفی است که به هر مصرف‌کننده اختصاص داده می‌شود. در هدر سفارشی مثل X-API-Key یا در Query String ارسال می‌شود. مزیت اصلی‌اش این است که revoke سریع امکان‌پذیر است؛ اگر یک کلید لو رفت، فقط همان کلید غیرفعال می‌شود. این ویژگی در پروژه‌های B2B که هر مشتری کلید خودش را دارد، حیاتی است.
دو ضعف مهم API Key دارد. اول، هیچ اطلاعاتی از کاربر در خود حمل نمی‌کند؛ برای شناسایی نقش‌ها باید یک lookup در دیتابیس انجام دهید که بار اضافه دارد. دوم، اگر از طریق URL ارسال شود، در لاگ سرور و history مرورگر باقی می‌ماند. برای امنیت کلید، اصول مدیریت رمز عبور امن راهنمای کاملی دارد.
JWT: استاندارد اپلیکیشن‌های کاربرمحور
JWT (JSON Web Token) یک توکن امضاشده است که سه بخش دارد: هدر، payload و امضا. payload می‌تواند اطلاعات کاربر، نقش و زمان انقضا را حمل کند. مزیت اصلی JWT، stateless بودن است؛ سرور نیازی به lookup در دیتابیس ندارد چون همه اطلاعات موردنیاز در توکن هست. این ویژگی در سیستم‌های توزیع‌شده و میکروسرویس‌ها بسیار ارزشمند است.
اما JWT چند نکته ظریف دارد که در پروژه‌ها زیاد اشتباه می‌شود. اول، JWT رمزنگاری نیست، فقط امضاست؛ اطلاعات حساس را در آن نگذارید. دوم، انقضای توکن باید کوتاه باشد؛ معمولاً بین ۱۵ تا ۶۰ دقیقه. سوم، برای revoke سریع باید یک لیست سیاه یا مکانیزم refresh token داشته باشید. جزئیات فنی در احراز هویت در REST API آمده است.
برای پیاده‌سازی JWT در پایتون، ساخت REST API با پایتون راهنمای کاملی دارد و برای PHP، ساخت API با PHP نکات کاربردی ارائه می‌دهد.
OAuth 2.0: استاندارد APIهای عمومی
OAuth 2.0 یک پروتکل احراز هویت تفویضی است؛ به جای اینکه رمز عبور خود را به اپلیکیشن سوم بدهید، به آن اجازه دسترسی محدود می‌دهید. مکانیزم آن با چند نوع flow پیاده می‌شود که مهم‌ترین آن‌ها Authorization Code و Client Credentials هستند. برای APIهای عمومی که توسعه‌دهندگان خارجی از آن‌ها استفاده می‌کنند، OAuth استاندارد صنعت است.
پیچیدگی OAuth بیشتر از سه روش دیگر است و معمولاً فقط وقتی ارزش دارد که بخواهید دسترسی تفویضی واقعی بدهید. اگر API شما فقط توسط اپلیکیشن‌های خودتان مصرف می‌شود، JWT یا API Key کافی است. اما اگر می‌خواهید مانند گوگل و گیت‌هاب، به کاربران اجازه دهید با حساب شما به سرویس‌های دیگر وصل شوند، OAuth اجتناب‌ناپذیر است.
جدول مقایسه و راهنمای انتخاب
برای تصمیم‌گیری سریع، جدول زیر را بر اساس تجربه پروژه‌ها آماده کرده‌ام:
| روش | مناسب برای | نقطه قوت | نقطه ضعف |
|---|---|---|---|
| Basic Auth | محیط تست، سرویس داخلی محدود | پیاده‌سازی ساده | ارسال رمز خام در هر درخواست |
| API Key | APIهای B2B، سرویس داخلی | Revoke سریع، سادگی | نیاز به lookup، بدون اطلاعات کاربر |
| JWT | اپلیکیشن موبایل، میکروسرویس | Stateless، اطلاعات در توکن | Revoke دشوار، نیاز به refresh |
| OAuth 2.0 | APIهای عمومی، ورود با سرویس‌های دیگر | استاندارد، دسترسی تفویضی | پیچیدگی بالا |
قاعده ساده‌ای که در پروژه‌ها به کار می‌برم: اگر فقط یک سرویس داخلی مصرف‌کننده است، API Key. اگر اپلیکیشن موبایل با کاربران نهایی، JWT. اگر API عمومی، OAuth. برای درک تفاوت احراز هویت و مجوزدهی، تفاوت احراز هویت و مجوزدهی را ببینید.
اشتباهات رایج در پیاده‌سازی
چند اشتباه که در پروژه‌های مختلف دیده‌ام:
- ارسال توکن در URL: در لاگ سرور و history مرورگر ذخیره می‌شود و ریسک زیادی دارد.
- عدم استفاده از HTTPS: توکن قوی بدون HTTPS هم بی‌ارزش است چون در مسیر قابل دزدیدن است.
- انقضای طولانی توکن: توکن یک‌ساله در عمل یک رمز عبور ثابت است.
- ذخیره توکن به صورت خام: در صورت نفوذ، تمام توکن‌ها در دست مهاجم قرار می‌گیرد.
- عدم rate limiting روی endpoint لاگین: راه را برای brute force باز می‌کند.
برای درک عمیق‌تر این دسته خطاها، امنیت API و بهترین روش‌ها و حمله Brute Force چیست را ببینید.
در ووکامرس، احراز هویت REST API از طریق Consumer Key و Secret انجام می‌شود. اگر با این بخش کار می‌کنید، اتصال ووکامرس به API های خارجی نکات مهمی درباره مدیریت کلیدها دارد. برای امنیت بیشتر فروشگاه، امنیت فروشگاه ووکامرس را ببینید.
هیچ روش احراز هویتی به‌تنهایی امن نیست. امنیت از ترکیب چند لایه می‌آید: پروتکل درست، پیاده‌سازی دقیق، پایش فعال و بازبینی مداوم.
پرسش‌های پرتکرار درباره احراز هویت API
آیا JWT جایگزین Session است؟ در APIهای stateless بله، اما در اپلیکیشن‌های وبی که فقط مرورگر مصرف‌کننده است، Session همچنان گزینه ساده‌تر و امن‌تری است.
آیا می‌توان چند روش احراز هویت را همزمان استفاده کرد؟ بله و در پروژه‌های بزرگ رایج است. مثلاً API Key برای سرویس‌های داخلی و JWT برای اپلیکیشن موبایل. اما هر endpoint باید یکی را به‌عنوان مرجع داشته باشد.
بهترین مدت انقضا برای توکن چقدر است؟ برای JWT معمولاً بین ۱۵ تا ۶۰ دقیقه. بیشتر از ۲۴ ساعت، توکن را به رمز عبور ثابت تبدیل می‌کند.
چگونه revoke توکن را پیاده کنم؟ برای API Key، حذف از دیتابیس کافی است. برای JWT، به یک لیست سیاه یا مکانیزم refresh با نسخه‌بندی توکن نیاز دارید. برای OAuth، endpoint revoke استاندارد وجود دارد.
آیا احراز هویت کافی است یا مجوزدهی هم لازم است؟ هر دو لازم هستند. احراز هویت می‌گوید کی هستی، مجوزدهی می‌گوید چه کاری می‌توانی بکنی. برای درک تفاوت، تفاوت احراز هویت و مجوزدهی را ببینید.
برای مقایسه معماری‌های مدرن که بر احراز هویت اثر می‌گذارند، تفاوت REST و GraphQL را ببینید. برای مستندسازی احراز هویت، مستندسازی API و مستندسازی REST API با Swagger را مطالعه کنید.
اگر با ووکامرس کار می‌کنید، استفاده از REST API در وردپرس و REST API در وردپرس نکات کاربردی دارند. برای آشنایی با ویکی‌پدیا در این موضوع، احراز هویت در ویکی‌پدیا توضیح کامل دارد.
برای مبانی امنیتی، راهنمای امنیت وردپرس برای مبتدیان و چگونه REST API امن بسازیم را ببینید. اگر با 2FA کار می‌کنید، تأثیر 2FA بر امنیت و فعال‌سازی 2FA برای کاربران وردپرس را ببینید.
نگاهی از تجربه پروژه‌های واقعی
سه چیز بعد از سال‌ها کار با احراز هویت API یاد گرفتم. اول، امنیت را از روز اول بگنجانید نه به عنوان افزودنی. دوم، هر endpoint باید یک روش احراز هویت مشخص و قابل مستندسازی داشته باشد. سوم، پایش و لاگ‌گیری همانقدر مهم است که خود احراز هویت. برای سایر روش‌های امنیتی، امنیت وب و اصول آن و بهترین روش‌های احراز هویت کاربران را ببینید. برای ورود بدون رمز، ورود بدون رمز عبور نکات جالبی دارد. اگر با GraphQL کار می‌کنید، GraphQL یا REST در پروژه‌های واقعی را ببینید.
اگر تجربه‌ای از انتخاب روش احراز هویت در پروژه واقعی دارید، در دیدگاه بنویسید. برای من جالب است بدانم کدام بُعد بیشترین نقش را در تصمیم شما داشته و چه مشکلاتی در پیاده‌سازی آن رخ داده است. 🔐
نویسنده در وردپرس کار.