19 अप्रैल 2025·8 मिनट
आधुनिक फ्रेमवर्क प्रमाणीकरण और प्राधिकरण को कैसे संभालते हैं
जानें कि आधुनिक फ्रेमवर्क प्रमाणीकरण और प्राधिकरण को कैसे लागू करते हैं: सत्र, टोकन, OAuth/OIDC, मिडलवेयर, रोल्स, नीतियाँ, और मुख्य सुरक्षा जोखिम।
जानें कि आधुनिक फ्रेमवर्क प्रमाणीकरण और प्राधिकरण को कैसे लागू करते हैं: सत्र, टोकन, OAuth/OIDC, मिडलवेयर, रोल्स, नीतियाँ, और मुख्य सुरक्षा जोखिम।
Authentication पूछता है “आप कौन हैं?” Authorization पूछता है “आप क्या कर सकते हैं?” आधुनिक फ्रेमवर्क इन्हें संबंधित पर अलग चिंताएं मानते हैं, और यह अलगाव एक बड़े ऐप के साथ सुरक्षा को स्थिर रखने का एक मुख्य कारण है।
Authentication उस बारे में है कि उपयोगकर्ता (या सेवा) यह साबित करे कि वह वही है जो वह दावा कर रहा है। फ्रेमवर्क सामान्यतः एक ही तरीके को हार्ड-कोड नहीं करते; इसके बजाय वे पासवर्ड लॉगिन, सोशल लॉगिन, SSO, API कुंजी, और सेवा क्रेडेंशियल जैसी सामान्य विकल्पों के लिए एक्सटेंशन पॉइंट देते हैं।
Authentication का परिणाम एक पहचान होती है: एक यूज़र ID, अकाउंट स्थिति, और कभी-कभी बुनियादी एट्रीब्यूट्स (जैसे whether email verified)। महत्वपूर्ण बात: authentication यह तय नहीं करता कि कोई क्रिया अनुमत है—यह केवल यह बताता है कि कौन अनुरोध कर रहा है।
Authorization स्थापित पहचान और अनुरोध संदर्भ (रूट, संसाधन का मालिक, टेनेंट, स्कोप, पर्यावरण, आदि) का उपयोग करके यह तय करता है कि कोई क्रिया अनुमत है या नहीं। यही वह जगह है जहाँ रोल्स, परमिशन्स, पॉलिसीज़, और संसाधन-आधारित नियम रहते हैं।
फ्रेमवर्क authorization नियमों को authentication से अलग रखते हैं ताकि आप:
अधिकांश फ्रेमवर्क अनुरोध जीवनचक्र में केंद्रीकृत प्वाइंट्स के माध्यम से नियम लागू करते हैं:
हालाँकि नाम अलग होते हैं, बिल्डिंग ब्लॉक्स परिचित हैं: एक identity store (यूज़र्स और क्रेडेंशियल्स), एक session या token जो अनुरोधों के बीच पहचान ले जाता है, और middleware/guards जो authentication और authorization को सुसंगत रूप से लागू करते हैं।
इस लेख के उदाहरण वैचारिक बने रहते हैं ताकि आप इन्हें अपनी पसंद के फ्रेमवर्क से मैप कर सकें।
किसी फ्रेमवर्क को “किसी को लॉग इन” करने से पहले दो चीज़ों की ज़रूरत होती है: पहचान डेटा देखने के लिए एक जगह (the identity store) और कोड में उस पहचान का एक सुसंगत प्रतिनिधित्व (the user model)। आधुनिक फ्रेमवर्क्स में कई “authentication फीचर्स” इन दोनों टुकड़ों के इर्द-गिर्द अभिसरण होते हैं।
फ्रेमवर्क सामान्यतः कई बैकएंड को सपोर्ट करते हैं, या तो बिल्ट-इन या प्लगइन्स के माध्यम से:
मुख्य फर्क यह है कि कौन सत्य का स्रोत है। डेटाबेस यूज़र्स के साथ, आपकी ऐप क्रेडेंशियल्स और प्रोफ़ाइल डेटा की मालिक है। IdP या डायरेक्टरी के साथ, आपकी ऐप अक्सर एक “लोकल शैडो यूजर” स्टोर करती है जो बाहरी पहचान से लिंक करता है।
यहाँ कुछ मानक फ़ील्ड्स होते हैं जिन्हें अधिकांश टीमें स्टैण्डर्डाइज़ करती हैं:
is_verified, is_active, is_locked, deleted_at।ये फ़्लैग्स महत्वपूर्ण हैं क्योंकि authentication केवल “सही पासवर्ड?” नहीं है—यह भी है “क्या यह अकाउंट अभी साइन-इन करने की अनुमति रखता है?”
एक व्यावहारिक identity store सामान्य जीवनचक्र घटनाओं का समर्थन करता है: पंजीकरण, ईमेल/फोन सत्यापन, पासवर्ड रीसेट, संवेदनशील परिवर्तन के बाद सत्र रिवोकेशन, और निष्क्रियकरण या सॉफ्ट-डिलीशन। फ्रेमवर्क अक्सर प्रिमिटिव्स (टोकन, टाइमस्टैम्प, हुक्स) प्रदान करते हैं, पर आप ही नियम निर्धारित करते हैं: एक्सपायरी विंडो, रेट लिमिट, और जब एक अकाउंट डिसेबल होता है तो मौजूद सत्रों के साथ क्या होता है।
अधिकांश आधुनिक फ्रेमवर्क एक्सटेंशन पॉइंट्स जैसे user providers, adapters, या repositories देते हैं। ये घटक “दिया गया लॉगिन पहचानकर्ता, उपयोगकर्ता लाओ” और “दिया गया उपयोगकर्ता ID, वर्तमान उपयोगकर्ता लोड करो” को आपके चुने हुए स्टोर में अनुवाद करते हैं—चाहे वह SQL क्वेरी हो, किसी IdP को कॉल, या एक एंटरप्राइज़ डायरेक्टरी लुकअप।
Session-based authentication क्लासिक तरीका है जिसे कई वेब फ्रेमवर्क अभी भी डिफ़ॉल्ट कहते हैं—विशेषकर सर्वर-रेंडर किए गए ऐप्स में। विचार सरल है: सर्वर याद रखता है कि आप कौन हैं, और ब्राउज़र उस याददाश्त के लिए एक छोटा पॉइंटर रखता है।
सफल लॉगिन के बाद, फ्रेमवर्क सर्वर-साइड सत्र रिकॉर्ड बनाता है (अक्सर एक रैंडम session ID जो उपयोगकर्ता से मैप होता है)। ब्राउज़र को उस session ID वाली कुकी मिलती है। हर अनुरोध पर, ब्राउज़र स्वचालित रूप से कुकी वापस भेजता है, और सर्वर उसे उपयोगकर्ता खोजने के लिए उपयोग करता है।
क्योंकि कुकी केवल एक पहचानकर्ता है (खुद उपयोगकर्ता डेटा नहीं), संवेदनशील जानकारी सर्वर पर रहती है।
आधुनिक फ्रेमवर्क सत्र कुकीज़ को चुराने या दुरुपयोग करने से मुश्किल बनाने के लिए सुरक्षित डिफ़ॉल्ट सेट करते हैं:
आप अक्सर इन्हें “session cookie settings” या “security headers” के तहत कॉन्फ़िगर होते देखते हैं।
फ्रेमवर्क आमतौर पर आपको सत्र स्टोर चुनने देते हैं:
ऊपर-नीचे, ट्रेडऑफ़ गति बनाम टिकाऊपन बनाम ऑपरेशनल जटिलता है।
लॉगआउट के दो अर्थ हो सकते हैं:
फ्रेमवर्क अक्सर "logout everywhere" को लागू करने के लिए एक उपयोगकर्ता “session version” ट्रैक करते हैं, कई session IDs स्टोर करते हैं, और उन्हें रद्द कर देते हैं। यदि आपको अधिक कठोर नियंत्रण चाहिए (तुरंत रद्दीकरण), तो session-based auth आमतौर पर टोकन्स की तुलना में सरल होती है क्योंकि सर्वर तुरंत किसी सत्र को भूल सकता है।
Token-based authentication सर्वर-साइड सत्र लुकअप को एक स्ट्रिंग से बदल देती है जिसे क्लाइंट हर अनुरोध पर प्रस्तुत करता है। फ्रेमवर्क आमतौर पर टोकन्स तब सुझाते हैं जब आपका सर्वर मुख्यतः API है (कई क्लाइंट्स द्वारा उपयोग), जब आपके पास मोबाइल ऐप्स हैं, जब आप SPA बना रहे हैं जो अलग बैकएंड से बोलती है, या जब सेवाएँ एक-दूसरे को कॉल करती हैं बिना ब्राउज़र सत्र के।
एक टोकन लॉगिन के बाद (या OAuth फ्लो के बाद) जारी किया गया एक एक्सेस क्रेडेंशियल है। क्लाइंट इसे बाद के अनुरोधों पर भेजता है ताकि सर्वर कॉलर को प्रमाणित कर सके और फिर कार्रवाई का निर्णय कर सके। अधिकांश फ्रेमवर्क इसे एक फ़र्स्ट-क्लास पैटर्न मानते हैं: एक “issue token” endpoint, ऐसा authentication middleware जो टोकन मान्य करता है, और guards/policies जो पहचान स्थापित होने के बाद चलते हैं।
Opaque tokens रैंडम स्ट्रिंग्स हैं जिनका क्लाइंट के लिए कोई अर्थ नहीं होता (उदा. tX9...)। सर्वर इन्हें डेटाबेस या कैश एंट्री के जरिए मान्य करता है। इससे रिवोकेशन सरल होता है और टोकन की सामग्री निजी रहती है।
JWTs (JSON Web Tokens) संरचित और साइन किए गए होते हैं। JWT आमतौर पर क्लेम्स जैसे उपयोगकर्ता पहचानकर्ता (sub), जारीकर्ता (iss), ऑडियंस (aud), जारी/समाप्ति समय (iat, exp), और कभी-कभी रोल्स/स्कोप्स रखते हैं। महत्वपूर्ण: JWTs डिफ़ॉल्ट रूप से एन्क्रिप्टेड नहीं होते—जो भी टोकन रखता है वह इसकी क्लेम्स पढ़ सकता है, भले ही वह नया टोकन फोर्ज न कर सके।
फ्रेमवर्क मार्गदर्शन सामान्यतः दो सुरक्षित डिफ़ॉल्ट पर मिलते हैं:
Authorization: Bearer <token> हेडर के जरिए भेजें। इससे वह CSRF जोखिम से बचता है जो स्वचालित रूप से भेजी जाने वाली कुकीज के साथ आता है, पर यह XSS रक्षा के लिए चुनौती बढ़ाता है क्योंकि जावास्क्रिप्ट आमतौर पर टोकन पढ़कर अटैच कर सकता है।HttpOnly, Secure, और SameSite बना सकें, और जब आप CSRF को ठीक से हैंडल करने को तैयार हों (अक्सर अलग CSRF टोकन के साथ)।Access टोकन्स को शॉर्ट-लाइव्ड रखें। लगातार लॉगिन को मजबूर न करने के लिए कई फ्रेमवर्क refresh tokens का समर्थन करते हैं: एक लंबी-आयु क्रेडेंशियल जिसका उपयोग केवल नए access टोकन्स बनाने के लिए होता है।
एक सामान्य संरचना है:
POST /auth/login → access token (और refresh token) लौटाता हैPOST /auth/refresh → refresh token को रोटेट करता है और नया access token देता हैPOST /auth/logout → सर्वर-साइड refresh tokens को निलंबित करता हैरोटेशन (हर बार नया refresh token जारी करना) नुकसान को सीमित करता है अगर refresh token चोरी हो जाए, और कई फ्रेमवर्क ऐसे हुक्स प्रदान करते हैं जो टोकन पहचानकर्ताओं को स्टोर करने, पुन: उपयोग का पता लगाने, और सत्रों को जल्दी रद्द करने की अनुमति देते हैं।
OAuth 2.0 और OpenID Connect (OIDC) अक्सर साथ में बताए जाते हैं, पर फ्रेमवर्क इन्हें अलग तरह से रखते हैं क्योंकि ये अलग समस्याओं का समाधान करते हैं।
OAuth 2.0 का उपयोग तब करें जब आपको delegated access चाहिए: आपकी ऐप को किसी उपयोगकर्ता की ओर से किसी API को कॉल करने की अनुमति चाहिए (उदा. कैलेंडर पढ़ना या रिपो पर पोस्ट करना) बिना उपयोगकर्ता का पासवर्ड संभाले।
OpenID Connect का उपयोग तब करें जब आपको login/identity चाहिए: आपकी ऐप यह जानना चाहती है कि उपयोगकर्ता कौन है और ID टोकन के साथ पहचान क्लेम्स प्राप्त करना चाहती है। प्रैक्टिकल में, “Login with X” आमतौर पर OIDC होता है जो OAuth 2.0 के ऊपर है।
अधिकांश आधुनिक फ्रेमवर्क और उनके auth लाइब्रेरी दो फ्लो पर केंद्रित होते हैं:
फ्रेमवर्क इंटीग्रेशन सामान्यतः एक callback route और हेल्पर middleware प्रदान करते हैं, पर आपको अभी भी आवश्यक कॉन्फ़िगरेशन सही तरीके से करनी चाहिए:
फ्रेमवर्क सामान्यतः प्रदाता डेटा को स्थानीय user मॉडल में सामान्यीकृत करते हैं। इस्त्रीक निर्णय यह है कि असल में प्राधिकरण को क्या चलाता है:
एक सामान्य पैटर्न: स्थिर पहचानकर्ताओं (जैसे sub) को स्थानीय उपयोगकर्ता से मैप करें, फिर प्रदाता के रोल्स/ग्रुप्स/क्लेमेंस को स्थानीय रोल्स या नीतियों में अनुवादित करें जिनका आपका ऐप नियंत्रण करता है।
पासवर्ड अभी भी कई ऐप्स में डिफ़ॉल्ट साइन-इन तरीका हैं, इसलिए फ्रेमवर्क सुरक्षित स्टोरेज पैटर्न और सामान्य गार्डरेल्स के साथ आते हैं। मूल नियम अपरिवर्तित है: आपको कभी भी डेटाबेस में पासवर्ड (या सरल हैश) नहीं स्टोर करना चाहिए।
आधुनिक फ्रेमवर्क और उनके auth लाइब्रेरी आमतौर पर bcrypt, Argon2, या scrypt जैसे इरादतन धीमे पासवर्ड हैशर्स का डिफ़ॉल्ट इस्तेमाल करते हैं। ये एल्गोरिद्म सलेटिंग शामिल करते हैं और बड़े पैमाने पर क्रैकिंग महंगी बनाते हैं।
एक सामान्य क्रिप्टोग्राफिक हैश (जैसे SHA-256) पासवर्ड्स के लिए असुरक्षित है क्योंकि यह तेज़ बनने के लिए डिज़ाइन किया गया है। यदि डेटाबेस लीक होता है, तो तेज़ हैश्स अटैकर्स को अरबों पासवर्ड अनुमान लगाने में सक्षम बनाते हैं। पासवर्ड हैशर्स वर्क फैक्टर्स (cost parameters) जोड़ते हैं ताकि आप हार्डवेयर के बेहतर होने पर सुरक्षा को समायोजित कर सकें।
फ्रेमवर्क आमतौर पर हुक्स (या मिडलवेयर/प्लगइन्स) प्रदान करते हैं ताकि आप हर एंडपॉइंट में हार्ड-कोड किए बिना नियम लागू कर सकें:
अधिकांश ईकोसिस्टम MFA जोड़ने का समर्थन करते हैं जो पासवर्ड सत्यापन के बाद एक दूसरा चरण होता है:
पासवर्ड रीसेट एक सामान्य अटैक पथ है, इसलिए फ्रेमवर्क अक्सर निम्न पैटर्न को प्रोत्साहित करते हैं:
एक अच्छा नियम: रिकवरी वैध उपयोगकर्ताओं के लिए आसान रखें, पर अटैकर्स के लिए स्वचालन महंगा बनाएं।
अधिकांश आधुनिक फ्रेमवर्क सुरक्षा को अनुरोध पाइपलाइन का हिस्सा मानते हैं: कदमों की एक श्रृंखला जो आपके controller/handler से पहले (और कभी-कभी बाद में) चलती है। नाम अलग हो सकते हैं—middleware, filters, guards, interceptors—पर विचार एक समान है: हर कदम अनुरोध पढ़ सकता है, संदर्भ जोड़ सकता है, या प्रोसेसिंग रोक सकता है।
एक सामान्य प्रवाह ऐसा दिखता है:
/account/settings)।फ्रेमवर्क आपको सुरक्षा परीक्षणों को बिजनेस लॉजिक के बाहर रखने के लिए प्रेरित करते हैं, ताकि controllers “क्या करना है” पर फोकसेड रहें न कि “कौन कर सकता है” पर।
Authentication वह चरण है जहाँ फ्रेमवर्क कुकीज़, session IDs, API कीज़, या bearer टोकन्स से user context स्थापित करता है। यदि सफल, तो यह एक अनुरोध-सीमित पहचान बनाता है—अक्सर user, principal, या context.auth ऑब्जेक्ट के रूप में एक्सपोज़ किया जाता है।
इस संलग्नता का महत्व यह है कि बाद के चरण (और आपका ऐप कोड) हेडर्स को फिर से पार्स या टोकन को फिर से मान्य नहीं करें। उन्हें पहले से भरी हुई user ऑब्जेक्ट पढ़नी चाहिए, जिसमें आमतौर पर शामिल होता है:
Authorization सामान्यतः लागू होता है:
दूसरे प्रकार की वजह से authorization हुक्स अक्सर controllers और सेवाओं के पास रहते हैं: उन्हें सही निर्णय लेने के लिए route params या डेटाबेस-लोडेड ऑब्जेक्ट्स चाहिए होते हैं।
फ्रेमवर्क दो सामान्य विफलता मोड अलग करते हैं:
अच्छी तरह डिज़ाइन किए सिस्टम 403 प्रतिक्रियाओं में विवरण लीक करने से बचते हैं; वे एक्सेस को अस्वीकार करते हैं बिना यह बताए कि कौन सा नियम फेल हुआ।
Authorization यह तंग प्रश्न का उत्तर देता है: “यह साइन-इन किया हुआ उपयोगकर्ता इस विशिष्ट चीज़ को अभी करने की अनुमति रखता है या नहीं?” आधुनिक फ्रेमवर्क सामान्यतः कई मॉडल सपोर्ट करते हैं, और कई टीमें इन्हें संयोजित करती हैं।
RBAC उपयोगकर्ताओं को एक या अधिक रोल्स असाइन करता है (उदा. admin, support, member) और उन रोल्स के आधार पर फीचर गेट करता है।
यह सोचने में आसान और जल्दी लागू करने योग्य है, विशेषकर जब फ्रेमवर्क requireRole('admin') जैसे हेल्पर्स देते हैं। रोल हायरेरकी (“admin implies manager implies member”) रिपीटिशन कम कर सकती है, पर यह भी अधिकार छुपा सकती है: एक पेरेंट रोल में छोटा सा बदलाव चुपके से पूरे ऐप में पहुँच दे सकता है।
RBAC व्यापक, स्थिर भेदभावों के लिए सबसे अच्छा काम करता है।
Permission-based authorization किसी क्रिया को संसाधन के खिलाफ जाँचता है, अक्सर इस रूप में व्यक्त:
read, create, update, delete, inviteinvoice, project, user, कभी-कभी ID या ownership के साथयह मॉडल RBAC से अधिक सटीक है। उदाहरण के लिए, “projects अपडेट कर सकता है” अलग है “केवल अपने मालिकाने वाले प्रोजेक्ट अपडेट कर सकता है”, जिसको both permission और डेटा कंडीशन दोनों की जाँच करनी होती है।
फ्रेमवर्क अक्सर एक केंद्रीय “can?” फ़ंक्शन (या सर्विस) के माध्यम से यह लागू करते हैं जिसे controllers, resolvers, workers, या टेम्पलेट्स से बुलाया जा सकता है।
Policies authorization लॉजिक को पुन:उपयोग योग्य इवैल्युएटर्स में पैकेज करती हैं: “एक उपयोगकर्ता टिप्पणी हटा सकता है अगर उसने उसे लिखा है या वह एक moderator है।” पॉलिसीज़ संदर्भ (user, resource, request) स्वीकार कर सकती हैं, जिससे वे आदर्श बन जाती हैं:
जब फ्रेमवर्क नीतियों को राउटिंग और मिडलवेयर में इंटिग्रेट करते हैं, तो आप नियमों को एंडपॉइंट्स के पार सुसंगत रूप से लागू कर सकते हैं।
Annotations (उदा. @RequireRole('admin')) हैंडलर के पास इरादा रखती हैं, पर जटिल नियमों के साथ बिखर सकती हैं।
कोड-आधारित चेक (authorizer को स्पष्ट कॉल) अधिक वर्बोज़ होते हैं, पर आमतौर पर परीक्षण और रिफैक्टर करने में आसान होते हैं। एक सामान्य सामंजस्य coarse gates के लिए annotations और विस्तृत लॉजिक के लिए policies का उपयोग है।
आधुनिक फ्रेमवर्क केवल लॉगिन करने में मदद नहीं करते—वे अधिकांश सामान्य “वेब ग्लू” हमलों के लिए बचाव भी प्रदान करते हैं जो authentication के आसपास होते हैं।
अगर आपकी ऐप session कुकीज़ का उपयोग करती है, तो ब्राउज़र उन्हें स्वचालित रूप से अनुरोधों के साथ जोड़ता है—कभी-कभी तब भी जब अनुरोध किसी दूसरी साइट से ट्रिगर किया गया हो। फ्रेमवर्क CSRF सुरक्षा आमतौर पर एक प्रति-सत्र (या प्रति-रिक्वेस्ट) CSRF टोकन जोड़ती है जिसे state-changing अनुरोधों के साथ भेजना अनिवार्य होता है।
सामान्य पैटर्न:
CSRF टोकन को SameSite कुकीज़ के साथ जोड़ें (अक्सर डिफ़ॉल्ट Lax) ताकि जोखिम कम हो, और सुनिश्चित करें कि आपका session cookie HttpOnly और Secure जहाँ उपयुक्त हों।
CORS कोई auth मैकेनिज़्म नहीं है; यह ब्राउज़र अनुमति प्रणाली है। फ्रेमवर्क आमतौर पर मिडलवेयर/कॉन्फ़िग प्रदान करते हैं ताकि विश्वसनीय ओरिजिन्स को आपके API कॉल करने की अनुमति दी जा सके।
गलत कॉन्फ़िगरेशन से बचें:
Access-Control-Allow-Origin: * के साथ Access-Control-Allow-Credentials: true (ब्राउज़र इसे रिजेक्ट कर देंगे और यह भ्रम दर्शाता है)।Origin हेडर को प्रतिबिंबित करना बिना सख्त allowlist के।Authorization) या मेथड्स को न भूलना, जिससे क्लाइंट curl में काम करे पर ब्राउज़र में फेल हो।अधिकांश फ्रेमवर्क सुरक्षित डिफ़ॉल्ट सेट करने या हेडर्स जोड़ना आसान बनाते हैं जैसे:
X-Frame-Options या Content-Security-Policy: frame-ancestors ताकि clickjacking रोका जा सके।Content-Security-Policy (स्क्रिप्ट/संसाधन नियंत्रण के लिए व्यापक)।Referrer-Policy और X-Content-Type-Options: nosniff सुरक्षित ब्राउज़र व्यवहार के लिए।वेलिडेशन यह सुनिश्चित करता है कि डेटा सही रूप में है; प्राधिकरण यह सुनिश्चित करता है कि उपयोगकर्ता कार्रवाई करने की अनुमति रखता है। एक वैध अनुरोध अभी भी प्रतिबंधित हो सकता है—फ्रेमवर्क सबसे अच्छे तब होते हैं जब आप दोनों लागू करें: जल्दी इनपुट वेलिडेट करें, फिर एक्सेस किए जा रहे विशिष्ट संसाधन पर परमिशन लागू करें।
ठीक "सही" auth पैटर्न काफी हद तक इस बात पर निर्भर करता है कि आपका कोड कहाँ चलता है और अनुरोध आपके बैकएंड तक कैसे पहुँचते हैं। फ्रेमवर्क कई विकल्प समर्थन कर सकते हैं, पर जो डिफ़ॉल्ट एक ऐप प्रकार में प्राकृतिक लगता है वह दूसरे में अजीब या जोखिम भरा हो सकता है।
SSR फ्रेमवर्क सामान्यतः कुकी-आधारित सत्रों के साथ सबसे अच्छा जोड़ते हैं। ब्राउज़र स्वतः कुकी भेजता है, सर्वर सत्र देखता है, और पेजेज़ यूज़र संदर्भ के साथ रेंडर कर सकते हैं बिना अतिरिक्त क्लाइंट कोड के।
एक व्यावहारिक नियम: session कुकीज़ को HttpOnly, Secure, और उचित SameSite सेटिंग के साथ रखें, और निजी डेटा रेंडर करने वाले हर अनुरोध के लिए सर्वर-साइड authorization चेक पर भरोसा रखें।
SPAs अक्सर जावास्क्रिप्ट से APIs को कॉल करती हैं, जिससे टोकन विकल्प अधिक प्रकट होते हैं। कई टीमें एक OAuth/OIDC फ्लो पसंद करती हैं जो शॉर्ट-लाइव्ड access टोकन्स प्रदान करे।
जब तक आवश्यक न हो, लंबे समय तक जीवित टोकन्स को localStorage में स्टोर करने से बचें; यह XSS का ब्लास्ट रेडियस बढ़ाता है। एक सामान्य विकल्प backend-for-frontend (BFF) पैटर्न है: SPA आपकी अपनी सर्वर से session कुकी के साथ बात करती है, और सर्वर upstream APIs के लिए टोकन्स को एक्सचेंज/होल्ड करता है।
मोबाइल ऐप ब्राउज़र कुकी नियमों पर उसी तरह भरोसा नहीं कर सकते। वे आमतौर पर PKCE के साथ OAuth/OIDC का उपयोग करते हैं, और refresh टोकन्स को प्लेटफ़ॉर्म के सुरक्षित स्टोरेज (Keychain/Keystore) में रखते हैं।
“खोया हुआ डिवाइस” रिकवरी की योजना बनाएं: refresh टोकन्स रिवोक करें, क्रेडेंशियल्स रोटेट करें, और पुनः-प्रमाणीकरण को ग्लाइडर बनाएं—खासकर जब MFA सक्षम हो।
कई सेवाओं के साथ, आप केंद्रीकृत पहचान और सर्विस-स्तरीय प्रवर्तन के बीच चुनाव करेंगे:
सर्विस-टू-सर्विस प्रमाणन के लिए, फ्रेमवर्क सामान्यतः mTLS (मजबूत चैनल पहचान) या OAuth client credentials (सर्विस अकाउंट्स) के साथ इंटीग्रेट करते हैं। कुंजी यह है कि कॉलर को प्रमाणित करें और उसे क्या करने की अनुमति है यह भी सुनिश्चित करें।
Admin "impersonate user" फीचर्स शक्तिशाली और खतरनाक दोनों होते हैं। स्पष्ट impersonation सत्रों को प्राथमिकता दें, admins के लिए री-प्रमाणीकरण/MFA की आवश्यकता रखें, और हमेशा ऑडिट लॉग लिखें (कौन किसे कब और कौन से कार्य किए)।
सुरक्षा फीचर्स तभी मदद करते हैं जब वे कोड बदलने पर भी काम करते रहें। आधुनिक फ्रेमवर्क authentication और authorization का परीक्षण करना आसान बनाते हैं, पर आपको ऐसे परीक्षणों की ज़रूरत है जो वास्तविक उपयोगकर्ता व्यवहार—और वास्तविक हमलावर व्यवहार—दोनों को दर्शाएँ।
क्या परीक्षण करना है इसे अलग करके शुरू करें:
अधिकांश फ्रेमवर्क टेस्ट हेल्पर्स के साथ आते हैं ताकि आपको हर बार सत्र या टोकन हाथ से रोल-रोल न करना पड़े। सामान्य पैटर्न्स में शामिल हैं:
एक व्यावहारिक नियम: हर “हैप्पी पाथ” टेस्ट के साथ एक “deny होना चाहिए” टेस्ट जोड़ें जो साबित करे कि authorization चेक वास्तव में चल रहा है।
यदि आप इन फ्लोज़ पर तीव्रता से काम कर रहे हैं, तो रैपिड प्रोटोटाइपिंग और सुरक्षित रोलबैक का समर्थन करने वाले टूल मददगार होते हैं — यह उन परिस्थितियों में उपयोगी है जब आप session बनाम token अप्रोच का प्रयोग कर रहे हों और middleware/guards व policy चेक्स को परखना चाहते हों।
जब कुछ गलत होता है, आप जल्दी और आत्मविश्वास से जवाब चाहते हैं।
लॉग और/या ऑडिट प्रमुख घटनाओं को रिकॉर्ड करें:
हल्के-मोटे मेट्रिक्स भी जोड़ें: 401/403 प्रतिक्रियाओं की दर, विफल लॉगिन्स में उछाल, और असामान्य टोकन रिफ्रेश पैटर्न।
Auth बग्स को टेस्टेबल व्यवहार की तरह ट्रीट करें: यदि यह रीग्रेs कर सकता है, तो यह एक टेस्ट का हकदार है।
Authentication पहचान को प्रमाणित करता है (किसने अनुरोध किया है)। Authorization यह तय करता है कि उस पहचान को क्या करने की अनुमति है — यह रूट, संसाधन का मालिकाना, टेनेंट, और स्कोप जैसी संदर्भ जानकारी का उपयोग करता है।
फ्रेमवर्क इन्हें अलग रखते हैं ताकि आप साइन-इन तरीके बदल सकें बिना परमिशन लॉजिक को फिर से लिखे।
अधिकांश फ्रेमवर्क अनुरोध पाइपलाइन में auth लागू करते हैं, जो आमतौर पर शामिल हैं:
user/principal जोड़ते हैंएक identity store उपयोगकर्ताओं और क्रेडेंशियल्स का स्रोत है (या बाहरी पहचान से लिंक)। एक user model वह तरीका है जिससे आपका कोड उस पहचान का प्रतिनिधित्व करता है।
व्यवहार में, फ्रेमवर्क दोनों की जरूरत रखते हैं ताकि वे जवाब दे सकें: “यदि यह पहचानकर्ता/टोकन है, तो वर्तमान उपयोगकर्ता कौन है?”
आम स्रोतों में शामिल हैं:
IdP/डायरेक्टरी का उपयोग करते समय कई ऐप एक स्थानीय “shadow user” रखते हैं ताकि OIDC sub जैसी स्थिर बाहरी IDs को ऐप-विशिष्ट रोल और डेटा से मैप किया जा सके।
सत्र (session) पहचान को सर्वर-साइड स्टोर करते हैं और कुकी को पॉइंटर के रूप में इस्तेमाल करते हैं। ये SSR के लिए बढ़िया हैं और अवैधकरण (revocation) सरल बनाते हैं।
टोकन (JWT/opaque) हर अनुरोध पर भेजे जाते हैं (अक्सर Authorization: Bearer ... के जरिए) और API, SPA, मोबाइल और सर्विस-टू-सर्विस मामलों के लिए उपयुक्त होते हैं।
फ्रेमवर्क आमतौर पर session कुकीज़ को हार्डेन करने के लिए सेट करते हैं:
HttpOnly (XSS से कुकी चोरी घटती है)Secure (केवल HTTPS)SameSite (क्रॉस-साइट भेजने को सीमित करता है; CSRF और लॉगिन फ्लोज़ पर असर)आपको अपने ऐप के लिए उपयुक्त मान चुने (उदा. बनाम ), खासकर जब क्रॉस-साइट ऑथ फ्लोज़ हों।
Opaque टोकन रैंडम स्ट्रिंग्स हैं जिन्हें सर्वर-लुकअप से मान्य किया जाता है (रिवोकेशन आसान, सामग्री निजी)।
JWTs साइन किए गए, सेल्फ-कंटेन्ट टोकन हैं जिनमें पढ़ने योग्य क्लेम्स होते हैं (sub, exp, रोल/स्कोप)। वे डिस्ट्रिब्यूटेड सिस्टम में सुविधाजनक हैं, पर रिवोकेशन कठिन हो सकता है जब तक आप शॉर्ट एक्सपाइरी और सर्वर-साइड नियंत्रण न रखें।
एक्सेस टोकन को छोटे समय के लिए रखें और केवल नए एक्सेस टोकन बनाने के लिए refresh टोकन का उपयोग करें।
सामान्य endpoints:
POST /auth/login → access + refreshPOST /auth/refresh → refresh टोकन को रोटेट करें + नया access जारी करेंPOST /auth/logout → refresh टोकन को निलंबित करेंरोटेशन और री-यूज़ डिटेक्शन से नुकसान सीमित होता है यदि कोई refresh टोकन लीक हो जाए।
OAuth 2.0 तब है जब आपको delegated API access चाहिए (किसी यूज़र की ओर से API कॉल करने की अनुमति)।
OpenID Connect (OIDC) लॉगिन/पहचान के लिए है — यह ID टोकन और मानकीकृत पहचान क्लेम जोड़ता है।
“Login with X” सामान्यतः OIDC होता है जो OAuth 2.0 पर बनाया गया होता है।
RBAC (roles) व्यापक दरवाज़े खोलने के लिए सरल है (उदा. admin बनाम member)। Permissions/policies सूक्ष्म नियमों के लिए ज़रूरी हैं (उदा. केवल अपनी ही डॉक्यूमेंट संपादित कर सकते हैं)।
एक आम पैटर्न:
LaxNone