دروازه‌های API (API Gateways) نقش مرکزی در معماری‌های مدرن ایفا می‌کنند — آن‌ها مسیریابی درخواست‌ها، محدودسازی نرخ (Rate Limiting)، ترجمه پروتکل‌ها و ایجاد نقطه ورود یکپارچه به سرویس‌های پس‌زمینه را بر عهده دارند. با رشد سیستم‌ها، طبیعی است که تیم‌ها تمایل پیدا کنند دروازه را برای مدیریت هویت و دسترسی نیز به‌کار گیرند.
اما این دقیقاً جایی است که مشکلات شروع می‌شوند.
در بسیاری از سازمان‌ها، دروازه‌ها برای اعتبارسنجی توکن‌ها، بررسی ادعاهای کاربر (Claims)، مدیریت ریدایرکت‌های ورود، و حتی تصمیم‌گیری‌های مجوزدهی استفاده می‌شوند. در نگاه اول، متمرکز کردن این وظایف در یک نقطه ممکن است کارآمد به نظر برسد، اما در عمل، انتقال منطق هویت به دروازه معمولاً نتیجه معکوس می‌دهد: پیچیدگی افزایش می‌یابد، انعطاف‌پذیری کاهش می‌یابد، و خطرات امنیتی پنهانی ایجاد می‌شود که تشخیص و رفع آن‌ها دشوار است.
این مقاله توضیح می‌دهد چرا باید مدیریت هویت را خارج از دروازه و توسط یک ارائه‌دهنده هویت تخصصی (Identity Provider) انجام داد، و چگونه تفکیک شفاف مسئولیت‌ها منجر به زیرساختی امن‌تر و قابل نگهداری‌تر می‌شود.
وظایف اصلی دروازه‌های API
دروازه‌های API برای مدیریت ترافیک ساخته شده‌اند، نه هویت.
وظایف اصلی آن‌ها شامل موارد زیر است:
-
مسیریابی درخواست‌ها به سرویس مناسب
-
اعمال محدودیت نرخ و جلوگیری از حملات Brute Force
-
کش کردن پاسخ‌ها برای کاهش بار سرویس‌ها
-
پایان‌دهی TLS و ترجمه پروتکل‌ها
-
ثبت و مانیتورینگ ترافیک
-
تبدیل درخواست/پاسخ برای سازگاری با فرمت‌ها
این وظایف بدون حالت (Stateless) و مبتنی بر زیرساخت‌اند. اما هویت و مجوز نیاز به وضعیت، سیاست، و ارتباطات پیچیده با سامانه‌های بیرونی دارند.
زمانی که دروازه‌ها بیش از حد مسئولیت می‌پذیرند
با افزایش قابلیت‌های دروازه‌ها، بسیاری از تیم‌ها از آن‌ها برای کارهایی فراتر از مسیریابی استفاده می‌کنند — از جمله مسئولیت‌های مرتبط با هویت.
برخی از این وظایف عبارت‌اند از:
-
اعتبارسنجی توکن (JWT Validation)
-
اجرای تصمیمات مجوزدهی
-
پیاده‌سازی پروتکل‌های OAuth و OpenID Connect
-
مدیریت ورود یکپارچه (Federation / SSO)
-
پردازش و تبدیل Claims
در حالی‌که پلاگین‌هایی برای این کارها وجود دارد، اما انتقال منطق هویت به دروازه باعث می‌شود معماری به‌شدت وابسته و شکننده شود. با تغییر الزامات هویت یا ارائه‌دهنده احراز هویت، پیکربندی دروازه باید بازنویسی شود — و این یعنی هزینه، خطا و ریسک بیشتر.
نقاط ضعف تکیه بر دروازه برای مدیریت هویت
۱. اعتبارسنجی ناقص توکن
دروازه‌ها معمولاً امضا و انقضای JWT را بررسی می‌کنند، اما زمینه‌ی واقعی را در نظر نمی‌گیرند — مثل ابطال توکن، انقضای Scope یا وضعیت نشست کاربر. بدون مکانیزم Introspection در زمان واقعی، کنترل دسترسی غیرقابل‌اعتماد می‌شود.
۲. منطق مجوزدهی پراکنده
وقتی تصمیمات دسترسی در سطح دروازه انجام می‌شود، قوانین دسترسی در مسیرهای مختلف تکرار می‌شوند و به ناهماهنگی منجر می‌گردند. این امر آزمون، ممیزی و نگهداری را دشوار می‌کند.
۳. پشتیبانی ضعیف از جریان‌های پیچیده (Federation & Delegation)
دروازه‌ها معمولاً برای فدراسیون هویت، تبادل توکن، یا مجوزدهی تفویض‌شده طراحی نشده‌اند. این محدودیت، توانایی سازمان برای تحول مدل‌های هویتی را کاهش می‌دهد.
۴. وابستگی شدید وظایف
ترکیب منطق حمل‌ونقل با منطق هویت، انعطاف‌پذیری را از بین می‌برد. تغییر ارائه‌دهنده هویت یا افزودن احراز چندمرحله‌ای ممکن است کل لایه API را تحت‌تأثیر قرار دهد.
۵. قابلیت مشاهده پایین (Poor Observability)
وقتی منطق هویت در پیکربندی دروازه پنهان است، تشخیص منبع خطا — چه در مسیر، چه در Claim یا در سرویس هویت — دشوار می‌شود.
واگذاری هویت برای مقیاس‌پذیری بهتر
راه‌حل ایمن‌تر و مقیاس‌پذیرتر این است که مسئولیت هویت را به ارائه‌دهنده هویت (Identity Provider) واگذار کنیم.
در این مدل:
-
سرور OAuth یا OpenID Connect احراز هویت و صدور توکن را انجام می‌دهد.
-
دروازه فقط صحت توکن را بررسی کرده و سیاست‌های دسترسی را اجرا می‌کند.
-
مدیریت نشست، Federation و تبادل توکن به سرویس هویت سپرده می‌شود.
مزایا:
-
منطق هویت متمرکز و قابل مدیریت‌تر می‌شود.
-
ورود یکپارچه و احراز چندمرحله‌ای به‌راحتی پشتیبانی می‌شوند.
-
اعتبارسنجی توکن‌ها دقیق‌تر است.
-
پیکربندی دروازه ساده و قابل نگهداری می‌ماند.
الگوهای پیاده‌سازی برای واگذاری هویت
۱. Token Introspection
در این روش، دروازه توکن را مستقیماً اعتبارسنجی نمی‌کند بلکه آن را به پایان‌نقطه Introspection در ارائه‌دهنده هویت ارسال می‌کند تا وضعیت و Claims آن بررسی شود.
۲. Phantom Token Pattern
در این مدل، کلاینت یک توکن مبهم (Opaque Token) دریافت می‌کند. دروازه آن را با یک JWT داخلی از ارائه‌دهنده هویت مبادله کرده و درخواست را با آن به سرویس‌ها ارسال می‌کند.
مزایا:
-
ساختار داخلی توکن از دید کلاینت پنهان می‌ماند.
-
پیچیدگی دروازه کاهش می‌یابد.
-
مجوزدهی دقیق‌تر در سرویس‌ها ممکن می‌شود.
۳. Split Token Pattern
نوعی از الگوی بالا است که برای دروازه‌های توزیع‌شده مناسب‌تر است. در این حالت، بخش امضا نزد کلاینت باقی می‌ماند و بقیه اجزای JWT در حافظه دروازه نگهداری می‌شوند.
مزایا:
-
امنیت بالا (دروازه توکن کامل را ندارد).
-
نیاز کمتر به فراخوانی شبکه‌ای برای اعتبارسنجی.
-
پشتیبانی بهتر از محیط‌های چندمنطقه‌ای.
۴. Backend-for-Frontend (BFF) Pattern
در برنامه‌های وب، یک Backend بین فرانت‌اند و ارائه‌دهنده هویت قرار می‌گیرد تا تمام منطق هویت را مدیریت کند.
توکن‌ها در سرور نگهداری می‌شوند و فرانت‌اند فقط با نشست امن کار می‌کند. این کار خطر افشای توکن را کاهش می‌دهد.
جمع‌بندی
دروازه‌های API برای مدیریت ترافیک و اجرای سیاست‌ها عالی هستند، اما برای مدیریت هویت طراحی نشده‌اند. ترکیب احراز هویت و مجوزدهی در دروازه باعث پیچیدگی، ناهماهنگی و شکاف‌های امنیتی می‌شود.
با انتقال مسئولیت هویت به یک ارائه‌دهنده تخصصی، معماری تمیز و امن باقی می‌ماند. دروازه روی مسیریابی و اجرا تمرکز می‌کند و سامانه هویت وظایف احراز، صدور توکن و تصمیم‌گیری دسترسی را انجام می‌دهد.
این تفکیک نه‌تنها یک انتخاب معماری هوشمندانه است، بلکه برای امنیت، مقیاس‌پذیری و پایداری بلندمدت ضروری است.
