// docs / baas security / auth0 hardening

چک‌لیست امنیت Auth0: ۲۲ مورد

Auth0 یک پلتفرم identity-as-a-service با سطح عظیمی است — اپلیکیشن‌ها، APIها (سرورهای resource)، مستأجران، اقدامات، قواعد (قدیمی)، اتصال‌ها و grantها. پیکربندی نادرست هر یک از آن‌ها یک bypass احراز هویت است. این چک‌لیست یک ممیزی ۲۲ موردی در سراسر اپلیکیشن‌ها، allowlistهای callback / logout، توکن‌ها و چرخش refresh، اقدامات سفارشی، RBAC، تشخیص ناهنجاری و پایش جاری است. هر مورد در داشبورد Auth0 در کمتر از ۱۰ دقیقه قابل تأیید است.

برای چک‌لیست معادل روی Clerk، چک‌لیست امنیت Clerk را ببینید. برای پس‌زمینه درباره این‌که چرا پیکربندی‌های نادرست لایه هویت نقاط کور ابزار هوش مصنوعی هستند، چرا ابزارهای کدنویسی هوش مصنوعی شکاف‌های امنیتی به جای می‌گذارند را ببینید.

نوع اپلیکیشن و انواع grant

نوع اپلیکیشن و انواع grant فعال‌شده پراثرترین تنظیمات در Auth0 هستند. اشتباه گرفتن آن‌ها کلاس‌هایی از حمله را باز می‌کند که هیچ مقدار کد فرانت‌اند آن را نمی‌بندد.

از Application Type = Single Page Application برای اپلیکیشن‌های فقط-مرورگر و Regular Web Application برای اپلیکیشن‌های server-rendered استفاده کنید. نوع اشتباه به انواع grant اشتباه اجازه می‌دهد — مثلاً یک Regular Web App با grant SPA جریان Implicit بدون PKCE را فعال می‌کند که توکن‌ها را از طریق fragmentهای URL نشت می‌دهد.
نوع grant Implicit را روی هر اپلیکیشن غیرفعال کنید. Dashboard → Application → Advanced Settings → Grant Types → uncheck Implicit. جریان Implicit توکن‌ها را در fragmentهای URL برمی‌گرداند، جایی که در تاریخچه مرورگر و تحلیل‌ها ثبت می‌شوند. به‌جای آن از Authorization Code با PKCE استفاده کنید.
grant Password را غیرفعال کنید مگر این‌که یک نیاز مستند داشته باشید. grant Resource Owner Password Credentials (ROPC) نیاز دارد خودتان گذرواژه‌های کاربر را مدیریت کنید — که اکثر آنچه برای Auth0 خریدید را شکست می‌دهد. آن را غیرفعال کنید مگر در حال یکپارچه‌سازی یک سیستم قدیمی باشید.
Authorization Code با PKCE را روی هر کلاینت عمومی فعال کنید. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256، OIDC Conformant = enabled. PKCE برای اپلیکیشن‌های موبایل و SPAها برای جلوگیری از قطع کد لازم است.

allowlistهای URL callback و logout

redirectهای باز در مسیر callback OAuth یک ابزار اولیه دزدی توکن است. allowlist Auth0 تنها دفاع شماست.

Allowed Callback URLs را روی مسیر callback تولیدی دقیق خود تنظیم کنید — بدون wildcard. https://yourapp.com/callback، نه https://yourapp.com/*. callbackهای wildcard به مهاجمان اجازه می‌دهد توکن‌ها را به subpathهای دلخواه روی دامنه شما redirect کنند.
Allowed Logout URLs را روی یک فهرست محدود تنظیم کنید. همان قانون: فقط URLهای صریح. یک redirect logout باز به مهاجمان اجازه می‌دهد صفحات phishing بسازند که شبیه وضعیت post-logout شما هستند.
Allowed Web Origins را فقط روی origin تولید خود تنظیم کنید. برای احراز هویت بی‌صدا (تجدید توکن از طریق iframe پنهان) استفاده می‌شود. یک origin با wildcard به صفحات مهاجم اجازه می‌دهد در برابر مستأجر شما احراز هویت بی‌صدا انجام دهند.
Allowed CORS origins را برای نقاط پایانی API تنظیم کنید، نه اپلیکیشن. Tenant Settings → Advanced → Allowed CORS origins. پیش‌فرض خالی است (محدود)؛ فقط originهای صریحی که کنترل می‌کنید را اضافه کنید.

توکن‌ها و چرخش refresh

طول عمر توکن، چرخش refresh و الگوریتم امضا شعاع انفجار هر نشت توکن را تعیین می‌کنند.

چرخش Refresh Token را فعال کنید. Application → Refresh Token Settings → Rotation. هر refresh یک refresh token جدید صادر می‌کند و قدیمی را بی‌اعتبار می‌کند. ترکیب با انقضای مطلق، این دزدی توکن را محدود می‌کند.
Refresh Token Reuse Interval را روی ۰ (یا تا حدی که تحمل replay شما اجازه می‌دهد) تنظیم کنید. فاصله استفاده مجدد به یک توکن اجازه می‌دهد در همان پنجره دو بار استفاده شود — آن را خاموش کنید مگر دلیل خاصی برای نگه داشتن آن داشته باشید.
Absolute Refresh Token Expiry را روی ۱۴-۳۰ روز تنظیم کنید، نه بی‌نهایت. Application → Refresh Token Expiration → Absolute Expiration. Auth0 به‌طور پیش‌فرض فقط روی Inactivity تنظیم شده، یعنی یک نشست idle می‌تواند سال‌ها باقی بماند.
JWT Signature Algorithm را روی RS256 تنظیم کنید. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 از امضای نامتقارن استفاده می‌کند پس کلاینت نمی‌تواند توکن‌ها را جعل کند. هرگز از HS256 برای اپلیکیشن‌های client-facing استفاده نکنید.
claimهای aud و iss را روی هر JWT که API شما دریافت می‌کند تأیید کنید. از SDK رسمی Auth0 در سمت سرور استفاده کنید — این‌ها را به‌طور خودکار تأیید می‌کند. تجزیه JWT دستی معمولاً اعتبارسنجی audience را رد می‌کند که یک bypass احراز هویت است.

اقدامات و کد سفارشی

Auth0 Actions (و Rules قدیمی) در سمت سرور در ورود و سایر رویدادهای چرخه عمر اجرا می‌شوند. آن‌ها به کل context درخواست دسترسی دارند. کد ناامن در این‌جا یک آسیب‌پذیری در سطح مستأجر است.

هرگز event.user یا event.transaction را به‌عنوان یک شیء کامل ثبت نکنید. این‌ها شامل آدرس‌های ایمیل، آدرس‌های IP و سایر PII هستند. فقط از ثبت در سطح فیلد استفاده کنید، و فقط آنچه نیاز دارید را ثبت کنید.
برای هر کلید API یا URL webhook از فروشگاه secrets استفاده کنید. Actions → Edit → Secrets. هرگز یک کلید API را به‌عنوان یک literal رشته در کد اقدام inline نکنید — کد برای هر کسی با دسترسی ویرایش Action روی مستأجر قابل مشاهده است.
ورودی‌ها را پیش از ذخیره به‌عنوان user_metadata یا app_metadata اعتبارسنجی کنید. یک اقدام self-service که event.body.name را به user.user_metadata.display_name می‌نویسد یک بردار XSS ذخیره‌شده است اگر فرانت‌اند شما آن فیلد را بدون escape کردن render کند.

RBAC و سرورهای resource

اگر از Auth0 RBAC استفاده می‌کنید، نگاشت نقش به مجوز لایه مجوزدهی شماست. اشتباه بگیرید و هر کاربر احراز هویت‌شده می‌تواند به نقاط پایانی admin برخورد کند.

Resource Serverها (APIها) را به‌صراحت در داشبورد Auth0 تعریف کنید، نه به‌صورت ad-hoc. هر API یک شناسه (audience)، اسکوپ‌ها و تنظیمات امضا دارد. بدون یک API ثبت‌شده، همه توکن‌ها برای "Auth0 Management API" ضمنی صادر می‌شوند — audience اشتباه.
Permissions را به‌ازای هر API پیکربندی کنید و در کد خود با claim scope آن‌ها را نیاز کنید. عضویت در نقش را در منطق اپلیکیشن خود بررسی نکنید؛ اسکوپ‌ها را در access token بررسی کنید. اسکوپ‌ها مکانیزم مجوزدهی native OAuth هستند.
آزمایش کنید که یک کاربر احراز هویت‌شده بدون نقش / اسکوپ مورد نیاز نمی‌تواند به نقاط پایانی ممتاز برخورد کند. به‌عنوان یک کاربر عادی وارد شوید، تلاش کنید POST /api/admin/users/delete را فراخوانی کنید. پاسخ باید 403 باشد.

تشخیص ناهنجاری و لاگ‌های مستأجر

Auth0 رویدادهای پرسیگنال منتشر می‌کند. آن‌ها را برای هشدار به تیم خود تنظیم کنید، نه این‌که فقط در یک buffer لاگ بنشینند.

Attack Protection را فعال کنید: Bot Detection، Brute Force، Suspicious IP Throttling. Dashboard → Security → Attack Protection. هر یک به‌طور پیش‌فرض روی پلن‌های رایگان خاموش است؛ برای تولید همه را روشن کنید.
لاگ‌های مستأجر را به یک SIEM یا لاگ‌های اپلیکیشن خود استریم کنید. Dashboard → Monitoring → Streams. Auth0 لاگ‌ها را به‌مدت ۳۰ روز در اکثر پلن‌ها نگه می‌دارد؛ نگه‌داری بلندمدت نیاز به استریم به سیستم خودتان دارد.
روی جهش‌های fcoa (احراز هویت cross-origin ناموفق) و fp (ورود ناموفق) هشدار بدهید. یک پشت‌سرهم از این‌ها در یک پنجره کوتاه credential stuffing است. به کانال on-call خود مسیریابی کنید.

گام‌های بعدی

یک اسکن FixVibe را روی URL تولیدی خود اجرا کنید — فحص baas.clerk-auth0 client secretهای Auth0 بسته‌بندی‌شده در جاوااسکریپت و سایر کلاس‌های افشای ارائه‌دهنده هویت را علامت‌گذاری می‌کند. برای معادل روی Clerk، چک‌لیست امنیت Clerk را ببینید. برای دیدگاه چتری در میان ارائه‌دهندگان BaaS، اسکنر پیکربندی نادرست BaaS را بخوانید.