// docs / baas security / auth0 hardening
Auth0 security checklist: 22 आइटम
Auth0 एक identity-as-a-service प्लेटफ़ॉर्म है जिसकी एक विशाल सतह है — applications, APIs (resource servers), tenants, actions, rules (legacy), connections, और grants। उनमें से किसी एक की misconfiguration एक auth bypass है। यह checklist applications, callback / logout allowlists, tokens और refresh rotation, custom actions, RBAC, anomaly detection, और ongoing monitoring में एक 22-आइटम audit है। हर आइटम 10 मिनट से कम में Auth0 Dashboard में verifiable है।
Clerk पर समकक्ष checklist के लिए, Clerk security checklist देखें। Identity-layer misconfigurations AI-tool blind spots क्यों हैं, इसकी पृष्ठभूमि के लिए, AI कोडिंग टूल security gaps क्यों छोड़ते हैं देखें।
Application type और grant types
Application type और enabled grant types Auth0 में सबसे उच्च-प्रभाव settings हैं। इन्हें गलत करने से ऐसे हमलों की classes खुलती हैं जिन्हें कोई भी frontend कोड बंद नहीं करेगा।
- Browser-only apps के लिए Application Type = Single Page Application और server-rendered apps के लिए Regular Web Application का उपयोग करें। गलत type गलत grant types की अनुमति देता है — उदाहरण के लिए, SPA grant के साथ एक Regular Web App PKCE-less Implicit flow को सक्षम करता है, जो URL fragments के माध्यम से tokens leak करता है।
- हर application पर Implicit grant type disable करें। Dashboard → Application → Advanced Settings → Grant Types → Implicit uncheck करें। Implicit flow URL fragments में tokens लौटाता है, जहाँ वे browser history और analytics में log होते हैं। इसके बजाय PKCE के साथ Authorization Code का उपयोग करें।
- जब तक आपके पास एक documented आवश्यकता न हो, Password grant disable करें। Resource Owner Password Credentials (ROPC) grant के लिए आपको स्वयं user passwords handle करने की आवश्यकता है — जिसके लिए आपने Auth0 खरीदा था, उसके अधिकांश को हराते हुए। Legacy system integrate करने तक इसे disable करें।
- हर public client पर PKCE के साथ Authorization Code enable करें। Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled। Code interception को रोकने के लिए mobile apps और SPAs के लिए PKCE आवश्यक है।
Callback और logout URL allowlists
OAuth callback path पर open redirects एक token-theft primitive हैं। Auth0 की allowlist आपकी एकमात्र रक्षा है।
- Allowed Callback URLs को अपने सटीक production callback path पर सेट करें — कोई wildcards नहीं।
https://yourapp.com/callback,https://yourapp.com/*नहीं। Wildcard callbacks हमलावरों को आपके domain पर arbitrary subpaths पर tokens redirect करने देते हैं। - Allowed Logout URLs को एक finite list पर सेट करें। समान नियम: केवल स्पष्ट URLs। एक open logout redirect हमलावरों को phishing pages craft करने देता है जो आपके post-logout state की तरह दिखती हैं।
- Allowed Web Origins को केवल अपने production origin पर सेट करें। Silent authentication (hidden iframe के माध्यम से token renewal) के लिए उपयोग किया जाता है। एक wildcard origin हमलावर pages को आपके tenant के विरुद्ध silent auth करने देता है।
- API endpoints के लिए Allowed CORS origins सेट करें, application के लिए नहीं। Tenant Settings → Advanced → Allowed CORS origins। Default खाली है (प्रतिबंधित); केवल वही explicit origins जोड़ें जिन्हें आप control करते हैं।
Tokens और refresh rotation
Token lifetime, refresh rotation, और signing algorithm किसी भी token leak की blast radius तय करते हैं।
- Refresh Token Rotation enable करें। Application → Refresh Token Settings → Rotation। हर refresh एक नया refresh token जारी करता है और पुराने को अमान्य करता है। Absolute expiry के साथ संयुक्त, यह token theft को सीमित करता है।
- Refresh Token Reuse Interval को 0 (या आपकी replay सहनशीलता जितनी कम हो) पर सेट करें। Reuse interval एक token को एक ही window में दो बार उपयोग करने देता है — इसे बंद कर दें जब तक आपके पास इसे रखने का कोई विशिष्ट कारण न हो।
- Absolute Refresh Token Expiry को infinity नहीं, 14-30 दिनों पर सेट करें। Application → Refresh Token Expiration → Absolute Expiration। Auth0 default रूप से केवल-Inactivity पर है, जिसका मतलब एक idle session वर्षों तक बनी रह सकती है।
- JWT Signature Algorithm को RS256 पर सेट करें। Application → Advanced → OAuth → JsonWebToken Signature Algorithm। RS256 asymmetric signing का उपयोग करता है ताकि client tokens forge नहीं कर सके। Client-facing applications के लिए कभी HS256 का उपयोग न करें।
- आपकी API द्वारा प्राप्त हर JWT पर
audऔरissclaims verify करें। Server side पर official Auth0 SDK का उपयोग करें — यह इन्हें automatically verify करता है। Hand-rolled JWT parsing आमतौर पर audience validation को skip करती है, जो एक auth bypass है।
Actions और custom code
Auth0 Actions (और legacy Rules) login और अन्य lifecycle events पर server-side चलते हैं। उनके पास पूरी request context तक access है। यहाँ असुरक्षित कोड एक tenant-wide vulnerability है।
- कभी
event.userयाevent.transactionको पूरे object के रूप में log न करें। इनमें email addresses, IP addresses, और अन्य PII होती है। केवल field-level logging का उपयोग करें, और केवल वही log करें जो आपको चाहिए। - किसी भी API key या webhook URL के लिए secrets store का उपयोग करें। Actions → Edit → Secrets। Action कोड में एक string literal के रूप में कभी API key inline न करें — कोड tenant पर Action editor access वाले किसी को भी दिखाई देता है।
- Inputs को user_metadata या app_metadata के रूप में persist करने से पहले validate करें। एक self-service action जो
event.body.nameकोuser.user_metadata.display_nameपर लिखता है, यदि आपका frontend उस field को escape किए बिना render करता है तो यह एक stored-XSS vector है।
RBAC और resource servers
यदि आप Auth0 RBAC का उपयोग करते हैं, तो role-to-permission mapping आपकी authorization layer है। इसे गलत करें और कोई भी authenticated user admin endpoints पर hit कर सकता है।
- Resource Servers (APIs) को Auth0 Dashboard में स्पष्ट रूप से define करें, on the fly नहीं। हर API में एक identifier (
audience), scopes, और signing settings हैं। एक registered API के बिना, सभी tokens implicit "Auth0 Management API" के लिए जारी किए जाते हैं — गलत audience। - प्रति API Permissions कॉन्फ़िगर करें और अपने कोड में
scopeclaim के साथ उनकी आवश्यकता रखें। अपनी application logic में role membership check न करें; access token में scopes check करें। Scopes OAuth-native authorization mechanism हैं। - परीक्षण करें कि आवश्यक role / scope के बिना एक authenticated user privileged endpoints पर hit नहीं कर सकता। एक सामान्य user के रूप में sign in करें,
POST /api/admin/users/deleteको call करने का प्रयास करें। Response403होना चाहिए।
Anomaly detection और tenant logs
Auth0 उच्च-signal events emit करता है। उन्हें केवल एक log buffer में बैठने के बजाय, अपनी team को alert करने के लिए सेट करें।
- Attack Protection enable करें: Bot Detection, Brute Force, Suspicious IP Throttling। Dashboard → Security → Attack Protection। प्रत्येक मुफ़्त tiers पर default रूप से बंद है; production के लिए उन सभी को चालू करें।
- Tenant logs को SIEM या अपनी application logs पर stream करें। Dashboard → Monitoring → Streams। Auth0 अधिकांश plans पर 30 दिनों के लिए logs रखता है; long-term retention के लिए अपने सिस्टम में एक stream की आवश्यकता है।
fcoa(failed cross-origin auth) औरfp(failed login) spikes पर alert करें। एक short window में इनकी एक burst credential stuffing है। अपने on-call channel पर route करें।
अगले कदम
अपने production URL के विरुद्ध एक FixVibe scan चलाएँ — baas.clerk-auth0 check JavaScript में bundled Auth0 client secrets और अन्य identity-provider exposure classes को flag करता है। Clerk पर समकक्ष के लिए, Clerk security checklist देखें। BaaS providers में umbrella दृश्य के लिए, BaaS misconfiguration scanner पढ़ें।