बैकएंड इंटरव्यू: PKCE के साथ OAuth Authorization Code Flow को समझाइए

समस्या और प्रासंगिक संदर्भ

आपके उत्पाद को उपयोगकर्ता के कैलेंडर पासवर्ड को हैंडल किए बिना, उसकी ओर से किसी थर्ड-पार्टी कैलेंडर को पढ़ने की आवश्यकता है। एक पब्लिक क्लाइंट के लिए PKCE के साथ संपूर्ण OAuth 2.0 ऑथराइजेशन कोड फ्लो की व्याख्या करें, जिसमें यह भी शामिल हो कि एप्लिकेशन बैकएंड और ऑथराइजेशन सर्वर को क्या-क्या वैलिडेट करना चाहिए।

मान लें कि क्लाइंट एक ब्राउज़र सिंगल-पेज एप्लिकेशन (SPA) या नेटिव एप्लिकेशन है। यह सभी डिप्लॉय किए गए इंस्टेंसेस में किसी एक स्टैटिक क्रेडेंशियल को गोपनीय रूप से सुरक्षित नहीं रख सकता, इसलिए यह एक पब्लिक क्लाइंट है। ऑथराइजेशन सर्वर उपयोगकर्ता को ऑथेंटिकेट करता है, सहमति (consent) प्राप्त करता है, और टोकन जारी करता है। रिसोर्स सर्वर कैलेंडर API को एक्सपोज़ करता है। प्रारंभिक स्कोप रीड-ओनली कैलेंडर एक्सेस है; रिफ्रेश टोकन जारी करना ऑथराइजेशन-सर्वर की पॉलिसी पर निर्भर करता है।

मार्च 2026 में प्रकाशित एक पब्लिक बैकएंड इंटरव्यू गाइड उम्मीदवारों से ऑथराइजेशन कोड ग्रांट, PKCE, पब्लिक और कॉन्फिडेंशियल क्लाइंट्स, तथा OAuth बनाम OpenID Connect की सीमा को समझाने के लिए कहती है। वर्तमान सुरक्षा आधारभूत मानक (baseline) OAuth 2.0 Security Best Current Practice है: पब्लिक क्लाइंट्स को अनिवार्य रूप से PKCE का उपयोग करना चाहिए, कॉन्फिडेंशियल क्लाइंट्स के लिए भी इसका उपयोग अनुशंसित है, ऑथराइजेशन सर्वर को PKCE डाउनग्रेड को रोकना चाहिए, और रजिस्टर्ड रीडायरेक्ट URIs का सटीक मिलान (exact matching) आवश्यक है।

यह एक बैकएंड प्रश्न है क्योंकि इसका मुख्य कौशल क्रॉस-सर्विस ऑथराइजेशन प्रोटोकॉल, टोकन सीमाओं और सुरक्षा नियंत्रणों को डिज़ाइन और वैलिडेट करना है। ब्राउज़र रीडायरेक्ट केवल इसका ट्रांसपोर्ट माध्यम हैं।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

पहला, क्या उम्मीदवार चारों भूमिकाओं (roles) को अलग-अलग समझ सकता है? रिसोर्स ओनर उपयोगकर्ता है, क्लाइंट कैलेंडर एग्रीगेशन उत्पाद है, ऑथराइजेशन सर्वर ऑथेंटिकेशन, सहमति और टोकन जारी करने का काम संभालता है, और रिसोर्स सर्वर कैलेंडर डेटा का ओनर है। क्लाइंट और उपयोगकर्ता के बीच भ्रम होने से अनुमतियों और टोकन ऑडियंस के बारे में आगे के सभी कथन गलत दिशा में चले जाते हैं।

दूसरा, क्या उम्मीदवार यह समझा सकता है कि ऑथराइजेशन कोड फ्लो के दो चरण (legs) क्यों होते हैं? ब्राउज़र को केवल एक अल्पकालिक (short-lived), सिंगल-यूज़ ऑथराइजेशन कोड प्राप्त होता है। क्लाइंट टोकन एंडपॉइंट पर इसका आदान-प्रदान करता है, जिससे एक्सेस टोकन ब्राउज़र रीडायरेक्ट URL में नहीं जाता है। PKCE फिर ऑथराइजेशन अनुरोध के लिए बनाए गए एक रैंडम सीक्रेट को उस कोड एक्सचेंज से बांधता है। यदि कोई पक्ष कोड को इंटरसेप्ट कर भी लेता है, लेकिन उसके पास code_verifier नहीं है, तो भी वह इसे रिडीम नहीं कर सकता।

तीसरा, क्या उम्मीदवार प्रत्येक नियंत्रण की ज़िम्मेदारी को सटीक रख सकता है?

अंत में, एक उत्कृष्ट उत्तर PKCE की सीमाओं को स्पष्ट करता है। यह किसी verifier या टोकन को पढ़ने से सेम-ओरिजिन XSS को नहीं रोकता है। यह TLS, रीडायरेक्ट वैलिडेशन, न्यूनतम विशेषाधिकार (least privilege), सुरक्षित टोकन स्टोरेज, या किसी ऑथेंटिकेशन प्रोटोकॉल का विकल्प नहीं है।

उत्तर देने से पहले स्पष्टीकरण हेतु प्रश्न

• क्या क्लाइंट पब्लिक है या कॉन्फिडेंशियल? एक SPA या नेटिव ऐप स्टैटिक क्लाइंट सीक्रेट के साथ पहचान साबित नहीं कर सकता। नियंत्रित बैकएंड वाला एक वेब एप्लिकेशन कॉन्फिडेंशियल हो सकता है और उसे PKCE का उपयोग करने के अलावा टोकन एंडपॉइंट पर ऑथेंटिकेट भी करना चाहिए।
• क्या लक्ष्य API ऑथराइजेशन है या उत्पाद में लॉगिन? कैलेंडर API एक्सेस OAuth का उपयोग करता है। यदि उत्पाद को उपयोगकर्ता की पहचान की आवश्यकता है, तो OIDC का उपयोग करें और एक्सेस टोकन से पहचान का अनुमान लगाने के बजाय ID टोकन को वैलिडेट करें।
• क्या क्लाइंट एक ही ऑथराइजेशन सर्वर का उपयोग करता है या टेनेंट-कॉन्फ़िगर किए गए पहचान प्रदाताओं (IdPs) का? मिक्स-अप हमलों को रोकने के लिए कई जारीकर्ताओं (issuers) के मामले में जारीकर्ता वैलिडेशन या अलग-अलग रीडायरेक्ट URIs की आवश्यकता होती है।
• क्या ऑफ़लाइन एक्सेस आवश्यक है? जब आवश्यक न हो तो रिफ्रेश टोकन का अनुरोध न करें। यदि यह आवश्यक है, तो रोटेशन, रिप्ले डिटेक्शन, रिवोकेशन और समाप्ति (expiry) को परिभाषित करें।
• कॉलबैक ट्रांजेक्शन स्टेट कहाँ स्टोर की जाती है? state → code_verifier बाइंडिंग को बनाए रखें। एक सिंगल ग्लोबल verifier एक साथ चलने वाले कई टैब्स को बाधित करता है; इसे URL या लॉग में डालने से गोपनीयता समाप्त हो जाती है।
• कैलेंडर की कितनी एक्सेस की आवश्यकता है? फीचर के लिए आवश्यक रीड-ओनली स्कोप से शुरुआत करें। राइट या अकाउंट-वाइड अनुमतियों के लिए ठोस औचित्य (justification) की आवश्यकता होती है।

30-सेकंड का उत्तर ढांचा (Framework)

"प्रत्येक ऑथराइजेशन प्रयास के लिए, मैं एक अप्रत्याशित (unpredictable) state और एक उच्च-एन्ट्रापी code_verifier जनरेट करता हूँ, फिर एक S256 code_challenge व्युत्पन्न करता हूँ। ब्राउज़र response_type=code, क्लाइंट ID, एक सटीक रजिस्टर्ड रीडायरेक्ट URI, न्यूनतम स्कोप, state और challenge के साथ ऑथराइजेशन एंडपॉइंट पर जाता है। उपयोगकर्ता केवल ऑथराइजेशन सर्वर पर ऑथेंटिकेट करता है। कॉलबैक एक अल्पकालिक, सिंगल-यूज़ कोड और वही state लौटाता है। क्लाइंट state को वैलिडेट करता है, उस ट्रांजेक्शन के verifier को लोड करता है, और कोड, रीडायरेक्ट URI और verifier को टोकन एंडपॉइंट पर भेजता है। सर्वर कोड, क्लाइंट, रीडायरेक्ट URI और challenge बाइंडिंग को वैलिडेट करने के बाद ही एक्सेस टोकन जारी करता है। एक पब्लिक क्लाइंट स्टैटिक सीक्रेट को क्रेडेंशियल के रूप में नहीं मान सकता; एक कॉन्फिडेंशियल क्लाइंट ऑथेंटिकेशन भी करता है। PKCE कोड एक्सचेंज की सुरक्षा करता है, state अनुरोध को सहसंबंधित करता है, और OIDC ID टोकन लॉगिन पहचान का समर्थन करता है।"

चरण-दर-चरण विस्तृत विवरण (Step-by-Step Deep Dive)

पहला चरण: सिंगल-यूज़ ऑथराइजेशन ट्रांजेक्शन बनाएं।

प्रत्येक "कैलेंडर कनेक्ट करें" क्रिया के लिए, क्लाइंट दो स्वतंत्र रैंडम मान जनरेट करता है:

• state एक अगम्य (unguessable) ट्रांजेक्शन ID है जो वर्तमान उपयोगकर्ता सेशन, अपेक्षित जारीकर्ता, कॉलबैक URI और ऑथराइजेशन के बाद के गंतव्य से बंधी होती है।
• code_verifier को क्रिप्टोग्राफ़िक रूप से सुरक्षित रैंडम स्रोत के साथ जनरेट किया जाता है। RFC 7636 इसे 43 से 128 अनरिजर्व्ड कैरेक्टर्स के रूप में परिभाषित करता है और कम से कम 256 बिट्स एन्ट्रापी की सिफारिश करता है।

क्लाइंट challenge को निम्नानुसार व्युत्पन्न करता है:

code_challenge = base64url_without_padding(
  SHA256(ASCII(code_verifier))
)
code_challenge_method = S256

प्रत्येक ट्रांजेक्शन के लिए एक अलग state → code_verifier रिकॉर्ड स्टोर करें। दो ब्राउज़र टैब एक साथ दो कैलेंडर कनेक्शन शुरू कर सकते हैं, इसलिए "नवीनतम verifier" एक मान्य डेटा मॉडल नहीं है। ट्रांजेक्शन को एक संक्षिप्त समाप्ति अवधि दें और सफलता या अंतिम विफलता के बाद इसे हटा दें। Verifier को रीडायरेक्ट URLs, एनालिटिक्स इवेंट्स या एप्लिकेशन लॉग्स में न डालें।

दूसरा चरण: ऑथराइजेशन अनुरोध का निर्माण करें।

क्लाइंट यूजर एजेंट को ऑथराइजेशन एंडपॉइंट पर भेजता है:

GET /authorize
  ?response_type=code
  &client_id=calendar-client
  &redirect_uri=registered-callback
  &scope=calendar.read
  &state=random-transaction-id
  &code_challenge=derived-challenge
  &code_challenge_method=S256

ऑथराइजेशन सर्वर क्लाइंट ID, रिस्पॉन्स टाइप, स्कोप और रीडायरेक्ट URI को वैलिडेट करता है। रीडायरेक्ट URI को किसी व्यापक डोमेन, मनमाने सबपाथ या उपयोगकर्ता-नियंत्रित अग्रेषण (forwarding) पैरामीटर के बजाय पूर्व-पंजीकृत मान से सटीक रूप से मेल खाना चाहिए। उपयोगकर्ता क्रेडेंशियल्स केवल ऑथराइजेशन सर्वर पर सबमिट किए जाते हैं। क्लाइंट को ऑथराइजेशन परिणाम प्राप्त होता है, उपयोगकर्ता का पासवर्ड कभी नहीं।

तीसरा चरण: अभी टोकन एंडपॉइंट को कॉल किए बिना कॉलबैक को प्रोसेस करें।

सहमति के बाद, ऑथराइजेशन सर्वर यूजर एजेंट को code और मूल state के साथ रजिस्टर्ड कॉलबैक पर रीडायरेक्ट करता है। क्लाइंट पहले अपने स्थानीय ट्रांजेक्शन को वैलिडेट करता है:

1. State मौजूद है, समाप्त (expired) नहीं हुई है, और उसका उपभोग नहीं किया गया है।
2. यह वर्तमान ब्राउज़र सेशन और अपेक्षित ऑथराइजेशन सर्वर से बंधी है।
3. कॉलबैक इस ट्रांजेक्शन के लिए रजिस्टर्ड एंडपॉइंट पर आया है।
4. एक त्रुटि प्रतिक्रिया (error response) अभी भी सही ट्रांजेक्शन को खोजने और सुरक्षित रूप से समाप्त करने के लिए state का उपयोग कर सकती है।

State मिसमैच होने पर "टोकन अनुरोध का प्रयास करके देखें कि क्या यह काम करता है" के बजाय फ्लो को निरस्त (abort) करें। ऑथराइजेशन कोड अल्पकालिक और सिंगल-यूज़ होना चाहिए। बार-बार रिडेम्पशन विफल होना चाहिए, और ऑथराइजेशन सर्वर को संभव होने पर उस कोड से पहले जारी किए गए टोकन को रद्द (revoke) कर देना चाहिए।

चौथा चरण: verifier के साथ कोड का आदान-प्रदान करें।

क्लाइंट यह टोकन अनुरोध भेजता है:

POST /token

grant_type=authorization_code
code=returned-authorization-code
redirect_uri=registered-callback
client_id=calendar-client
code_verifier=stored-verifier

ऑथराइजेशन सर्वर मूल ट्रांजेक्शन का पुनर्निर्माण करता है: कोड किस क्लाइंट और रीडायरेक्ट URI का है, क्या यह समाप्त हो गया है या पहले ही उपयोग किया जा चुका है, क्या ऑथराइजेशन अनुरोध में challenge शामिल था, और क्या इस verifier पर S256 लागू करने पर संग्रहीत challenge के बराबर मान प्राप्त होता है। यदि ऑथराइजेशन अनुरोध में challenge नहीं था लेकिन टोकन अनुरोध में verifier प्रस्तुत किया जाता है, तो सर्वर को ट्रांजेक्शन को नॉन-PKCE फ्लो में चुपचाप डाउनग्रेड नहीं करना चाहिए।

एक पब्लिक क्लाइंट पहचान के लिए क्लाइंट ID भेजता है, लेकिन पब्लिक कोड में शामिल एक स्टैटिक सीक्रेट इसे ऑथेंटिकेट नहीं कर सकता। एक कॉन्फिडेंशियल क्लाइंट इसके अतिरिक्त अपनी रजिस्टर्ड क्लाइंट ऑथेंटिकेशन विधि का उपयोग करता है। PKCE उस ऑथेंटिकेशन का पूरक है, न कि उसका विकल्प।

पांचवां चरण: एक अटैक पाथ के माध्यम से प्रत्येक नियंत्रण की व्याख्या करें।

मान लीजिए वैध क्लाइंट verifier V1 और challenge C1 बनाता है। एक हमलावर कॉलबैक कोड को इंटरसेप्ट करता है लेकिन उसे V1 नहीं पता है। हमलावर द्वारा चुना गया verifier C1 उत्पन्न नहीं करता है, इसलिए टोकन एक्सचेंज विफल हो जाता है। यह ऑथराइजेशन कोड इंटरसेप्शन के खिलाफ PKCE की मुख्य सुरक्षा है।

अब मान लीजिए कि हमलावर एक अलग ऑथराइजेशन ट्रांजेक्शन शुरू करता है और उस कोड को पीड़ित के कॉलबैक में इंजेक्ट करता है। पीड़ित ट्रांजेक्शन का एक अलग state और verifier होता है। State सहसंबंध या PKCE बाइंडिंग विफल हो जाती है, और क्लाइंट को प्रक्रिया निरस्त करनी होगी। ऑथराइजेशन सर्वर को यह भी याद रखना चाहिए कि किसी कोड के लिए challenge मौजूद था या नहीं, जिससे हमलावर को challenge हटाने और डाउनग्रेड ट्रिगर करने से रोका जा सके।

यदि कोई हमलावर रीडायरेक्ट URI को अपने नियंत्रित एंडपॉइंट में बदलता है, तो सटीक पंजीकरण और सटीक स्ट्रिंग मिलान इसे ऑथराइजेशन के दौरान अस्वीकार कर देते हैं। यदि कोई क्लाइंट कई ऑथराइजेशन सर्वरों का समर्थन करता है, तो उसे रिस्पॉन्स जारीकर्ता की तुलना ट्रांजेक्शन में सहेजे गए जारीकर्ता से भी करनी चाहिए या प्रत्येक जारीकर्ता के लिए एक अलग रीडायरेक्ट URI का उपयोग करना चाहिए। मिक्स-अप को रोकने के लिए केवल ऑथराइजेशन एंडपॉइंट URL को याद रखना पर्याप्त नहीं है।

छठा चरण: टोकन को उनके वास्तविक उद्देश्य तक सीमित रखें।

एक एक्सेस टोकन ऑथराइजेशन का प्रतिनिधित्व करता है और यह क्लाइंट के लिए उपयोगकर्ता पहचान का प्रमाण (assertion) नहीं है। रिसोर्स सर्वर यह सत्यापित करता है कि टोकन उसी के लिए लक्षित है और इसे आवश्यक संसाधनों और कार्रवाइयों तक सीमित करता है। क्लाइंट केवल calendar.read का अनुरोध करता है, अल्पकालिक एक्सेस टोकन का उपयोग करता है, और टोकन को URLs, लॉग्स और असंबंधित स्क्रिप्ट्स के लिए उपलब्ध पर्सिस्टेंट स्टोर्स से बाहर रखता है।

कोड टोकन में बदलने के बाद PKCE का काम समाप्त हो जाता है। यदि XSS SPA मेमोरी, ट्रांजेक्शन स्टोरेज या किसी एक्सेस टोकन को पढ़ सकता है, तो PKCE सीक्रेट को रिकवर नहीं कर सकता है। एक उच्च-जोखिम वाला ब्राउज़र एप्लिकेशन BFF (Backend-for-Frontend) का उपयोग कर सकता है: टोकन एक नियंत्रित बैकएंड में रहते हैं और ब्राउज़र केवल एक HttpOnly सेशन कुकी रखता है। यह जावास्क्रिप्ट टोकन एक्सपोजर को कम करता है लेकिन कुकी-सेशन, CSRF, बैकएंड स्केलिंग और API प्रॉक्सी लागत जोड़ता है।

यदि किसी पब्लिक क्लाइंट को रिफ्रेश टोकन प्राप्त होते हैं, तो ऑथराइजेशन सर्वर को सेंडर कंस्ट्रेंट (sender constraint) या रिफ्रेश-टोकन रोटेशन के माध्यम से रिप्ले का पता लगाना चाहिए। रोटेशन के साथ, प्रत्येक रिफ्रेश एक नया रिफ्रेश टोकन जारी करता है और पुराने को अमान्य कर देता है। पुराने मान का पुन: उपयोग संभावित समझौते (compromise) को इंगित करता है, इसलिए संपूर्ण ग्रांट फैमिली को रद्द कर दिया जाता है और उपयोगकर्ता फिर से ऑथराइज करता है।

सातवां चरण: OAuth, OIDC और अन्य ग्रांट्स को अलग करें।

OAuth उत्तर देता है कि क्या कोई क्लाइंट किसी उपयोगकर्ता की ओर से किसी रिसोर्स तक पहुंच सकता है। OIDC, OAuth के शीर्ष पर एक पहचान परत (identity layer) जोड़ता है ताकि क्लाइंट ID टोकन के माध्यम से लॉगिन को सत्यापित कर सके। OIDC कॉलबैक के लिए सिग्नेचर, जारीकर्ता, ऑडियंस, समाप्ति और nonce वैलिडेशन की भी आवश्यकता होती है। एक एक्सेस टोकन रिसोर्स सर्वर के लिए अभिप्रेत है; एक ID टोकन क्लाइंट के लिए अभिप्रेत है। वे विनिमेय (interchangeable) नहीं हैं।

जब कोई उपयोगकर्ता भाग नहीं लेता है और कोई सर्विस अपने अधिकार के तहत रिसोर्सेज तक पहुंचती है, तो क्लाइंट क्रेडेंशियल्स का उपयोग करें। एक सीमित-इनपुट डिवाइस (constrained-input device) डिवाइस ऑथराइजेशन फ्लो का उपयोग कर सकता है। इम्प्लिसिट फ्लो ऑथराइजेशन रिस्पॉन्स में एक एक्सेस टोकन रखता है, जिससे URL लीकेज और रिप्ले का जोखिम बढ़ जाता है; वर्तमान सर्वोत्तम अभ्यास कोड-रिटर्निंग फ्लो का समर्थन करता है। रिसोर्स ओनर पासवर्ड क्रेडेंशियल्स ग्रांट उपयोगकर्ता के पासवर्ड को क्लाइंट के सामने उजागर करता है और वर्तमान सुरक्षा बेसलाइन द्वारा प्रतिबंधित है।

आठवां चरण: विफलताओं को भी वैलिडेट करें, केवल हैप्पी पाथ को ही नहीं।

प्रोडक्शन मॉनिटरिंग को ऑथराइजेशन डिनायल, state मिसमैच, PKCE विफलता, कोड पुन: उपयोग, रीडायरेक्ट मिसमैच और रिफ्रेश-टोकन रिप्ले के बीच अंतर करना चाहिए। एक सिंगल "OAuth failed" काउंटर हमले के संकेतों और क्लाइंट कार्यान्वयन दोषों दोनों को छिपा देता है।

उच्च-गुणवत्ता वाला नमूना उत्तर

"मैं इसे किसी थर्ड-पार्टी कैलेंडर API तक पहुंचने वाले एक पब्लिक क्लाइंट के रूप में प्रस्तुत करूँगा। यह एक शेयर्ड सीक्रेट की सुरक्षा नहीं कर सकता, इसलिए एक SPA बंडल में एम्बेडेड सीक्रेट क्लाइंट ऑथेंटिकेशन नहीं है।

प्रत्येक ऑथराइजेशन की शुरुआत में, मैं एक अप्रत्याशित state और कम से कम 256 बिट्स एन्ट्रापी के साथ एक कोड verifier जनरेट करता हूँ, एक S256 challenge व्युत्पन्न करता हूँ, और उस state के तहत verifier, ब्राउज़र सेशन, जारीकर्ता, रीडायरेक्ट URI और समाप्ति को स्टोर करता हूँ। ऑथराइजेशन अनुरोध में कोड रिस्पॉन्स टाइप, क्लाइंट ID, सटीक रजिस्टर्ड रीडायरेक्ट URI, रीड-ओनली स्कोप, state और challenge शामिल होते हैं। उपयोगकर्ता केवल ऑथराइजेशन सर्वर पर ऑथेंटिकेट और सहमति देता है।

जब कॉलबैक कोड और state लौटाता है, तो मैं पहले यह साबित करता हूँ कि state वर्तमान सेशन से संबंधित है और अप्रयुक्त है, फिर इसके verifier को लोड करता हूँ। टोकन अनुरोध कोड, वही रीडायरेक्ट URI, क्लाइंट ID और verifier भेजता है। ऑथराइजेशन सर्वर एक्सेस टोकन जारी करने से पहले यह सत्यापित करता है कि कोड अल्पकालिक है, अप्रयुक्त है, इस क्लाइंट और रीडायरेक्ट URI को जारी किया गया है, और verifier का S256 मान challenge के बराबर है। इंटरसेप्ट किया गया कोड verifier के बिना बेकार है। सर्वर उस अनुरोध को भी अस्वीकार कर देता है जो PKCE को हटाने और एक्सचेंज को डाउनग्रेड करने का प्रयास करता है।

State ब्राउज़र अनुरोध को सहसंबंधित करता है, जबकि PKCE कोड एक्सचेंज को बांधता है; मैं उन्हें एक अस्पष्ट CSRF पैरामीटर में संकुचित नहीं करूँगा। एक कॉन्फिडेंशियल वेब ऐप टोकन एंडपॉइंट पर ऑथेंटिकेट भी करता है और उसे PKCE को बनाए रखना चाहिए। एक्सेस टोकन केवल कैलेंडर रिसोर्स सर्वर के लिए है। यदि उत्पाद लॉगिन के लिए इस फ्लो का उपयोग करता है, तो उसे OIDC की आवश्यकता होती है और उसे ID टोकन के सिग्नेचर, जारीकर्ता, ऑडियंस, समाप्ति और nonce को वैलिडेट करना चाहिए।

मैं गलत verifier, कोड पुन: उपयोग, क्रॉस-सेशन state, सटीक रीडायरेक्ट मिसमैच, गलत क्रम वाले टैब्स, PKCE डाउनग्रेड, और जारीकर्ता मिक्स-अप का परीक्षण करूँगा, और सत्यापित करूँगा कि लॉग में कोई कोड या टोकन नहीं हैं। PKCE किसी verifier या टोकन को चुराने से सेम-ओरिजिन XSS को नहीं रोक सकता। एक उच्च-जोखिम वाले ब्राउज़र क्लाइंट के लिए, मैं एक BFF का मूल्यांकन करूँगा जो सर्वर-साइड टोकन स्टोर करता है और ब्राउज़र को केवल एक HttpOnly सेशन कुकी देता है।"

सामान्य गलतियाँ

• क्लाइंट ID को सीक्रेट मानना → क्लाइंट ID ऑथराइजेशन अनुरोधों में दिखाई देती है और केवल क्लाइंट की पहचान करती है → पब्लिक क्लाइंट के लिए PKCE और कॉन्फिडेंशियल क्लाइंट के लिए वास्तविक क्लाइंट ऑथेंटिकेशन का उपयोग करें।
• केवल यह कहना कि "एक टोकन की तुलना में एक कोड अधिक सुरक्षित है" → यह नहीं समझाता कि इंटरसेप्ट किए गए कोड को क्यों रिडीम नहीं किया जा सकता → challenge-verifier बाइंडिंग और टोकन-एंडपॉइंट तुलना प्रदर्शित करें।
• plain का उपयोग करना या PKCE को छोड़ने की अनुमति देना → verifier उजागर हो सकता है या कोई हमलावर डाउनग्रेड ट्रिगर कर सकता है → S256 का उपयोग करें और ऑथराइजेशन सर्वर से PKCE रिकॉर्ड और लागू करवाएं।
• सेशन से जोड़े बिना state जनरेट करना → वैध मानों को ट्रांसप्लांट किया जा सकता है और समवर्ती फ्लो एक-दूसरे को ओवरराइट कर देते हैं → सिंगल-यूज़ state, सेशन, जारीकर्ता और verifier मैपिंग स्टोर करें।
• फ़ज़ी रीडायरेक्ट मिलान की अनुमति देना → एक कोड हमलावर-नियंत्रित सबपाथ या रीडायरेक्टर तक पहुंच सकता है → रीडायरेक्ट URIs को पूर्व-पंजीकृत करें और उनकी सटीक तुलना करें।
• एक्सेस टोकन को डीकोड करना और इसे लॉगिन पहचान मानना → इसकी ऑडियंस और सिमेंटिक्स रिसोर्स सर्वर के हो सकते हैं → OIDC लॉगिन का उपयोग करें और ID टोकन को वैलिडेट करें।
• यह दावा करना कि PKCE XSS को रोकता है → XSS सीधे किसी verifier, कोड या जारी टोकन को पढ़ सकता है → ब्राउज़र टोकन एक्सपोज़र कम करें, XSS को ठीक करें, और जोखिम के अनुसार BFF का मूल्यांकन करें।
• कोड, verifiers, या टोकन को लॉग करना → डायग्नोस्टिक्स रिडीमेबल सीक्रेट्स के एक्सपोजर को विस्तृत करते हैं → ट्रांजेक्शन IDs, एरर क्लासेस और गैर-रिडीमेबल सहसंबंध मानों को लॉग करें।

अनुवर्ती प्रश्न और प्रतिक्रियाएं

अनुवर्ती प्रश्न 1: क्या बैकएंड वाले पारंपरिक वेब ऐप को अभी भी PKCE की आवश्यकता है?

हाँ। टोकन एंडपॉइंट पर क्लाइंट ऑथेंटिकेशन यह साबित करता है कि एक कॉन्फिडेंशियल क्लाइंट के पास उसका संरक्षित क्रेडेंशियल है। PKCE इस ऑथराइजेशन अनुरोध को इस कोड एक्सचेंज से बांधता है और कोड इंजेक्शन और दुरुपयोग से अतिरिक्त सुरक्षा प्रदान करता है। ये नियंत्रण अलग-अलग संबंधों को बांधते हैं। सर्वर-साइड सेशन verifier और state को स्टोर कर सकता है जबकि ब्राउज़र केवल एक अप्रत्याशित सेशन पहचानकर्ता रखता है।

अनुवर्ती प्रश्न 2: यदि "कैलेंडर कनेक्ट करें" का अर्थ "कैलेंडर से साइन इन करें" भी हो तो क्या बदलता है?

एक्सेस टोकन या मनमाने UserInfo रिस्पॉन्स को लॉगिन प्रमाण के रूप में मानने के बजाय OIDC का उपयोग करें। openid स्कोप और nonce का अनुरोध करें। ID टोकन सिग्नेचर, जारीकर्ता, ऑडियंस, समाप्ति और nonce को वैलिडेट करें, फिर जारीकर्ता-सब्जेक्ट (issuer-subject) जोड़ी को बाहरी पहचान कुंजी के रूप में उपयोग करें। State ब्राउज़र ट्रांजेक्शन को बांधना जारी रखती है; Nonce ऑथेंटिकेशन अनुरोध को ID टोकन से बांधता है।

अनुवर्ती प्रश्न 3: जब प्रत्येक SaaS टेनेंट एक अलग जारीकर्ता कॉन्फ़िगर करता है तो क्या नया जोखिम प्रकट होता है?

क्लाइंट ऑथराइजेशन सर्वर A से रिस्पॉन्स को ऑथराइजेशन सर्वर B के टोकन एंडपॉइंट पर भेज सकता है, जिससे मिक्स-अप हो सकता है। ट्रांजेक्शन में अपेक्षित जारीकर्ता को सहेजें और रिस्पॉन्स जारीकर्ता को वैलिडेट करें। एक अन्य सुरक्षा उपाय प्रति जारीकर्ता एक अलग रीडायरेक्ट URI का उपयोग करना और यह सत्यापित करना है कि रिस्पॉन्स सही एंडपॉइंट पर आया है। ऑथराइजेशन और टोकन एंडपॉइंट समान विश्वसनीय जारीकर्ता मेटाडेटा से आने चाहिए।

अनुवर्ती प्रश्न 4: लंबे समय तक चलने वाले कैलेंडर सिंक्रोनाइज़ेशन के लिए आप रिफ्रेश टोकन की सुरक्षा कैसे करते हैं?

केवल आवश्यक स्कोप प्रदान करें और रिफ्रेश-टोकन रोटेशन या सेंडर कंस्ट्रेंट का उपयोग करें। रोटेशन के साथ, टोकन फैमिली को ट्रैक करें: प्रत्येक रिफ्रेश पुराने मान को अमान्य कर देता है, और पुराने रिफ्रेश टोकन का पुन: उपयोग सक्रिय फैमिली को रद्द कर देता है और नए ऑथराइजेशन की आवश्यकता होती है। क्लाइंट को सुरक्षित स्टोरेज, एक रिवोकेशन पाथ, अधिकतम जीवनकाल और निष्क्रियता समाप्ति (inactivity expiry) की भी आवश्यकता होती है। PKCE प्रारंभिक कोड एक्सचेंज की सुरक्षा करता है, बाद में चुराए गए रिफ्रेश टोकन की नहीं।

अनुवर्ती प्रश्न 5: दो टैब अलग-अलग कैलेंडर खातों को कनेक्ट करते समय रुक-रुक कर विफल क्यों होते हैं?

एक सामान्य कारण एक ग्लोबल state या verifier है: दूसरा टैब पहले को ओवरराइट कर देता है। कॉलबैक को state द्वारा एक स्वतंत्र ट्रांजेक्शन देखना चाहिए। उस रिकॉर्ड में verifier, अपेक्षित खाता या जारीकर्ता, रीडायरेक्ट URI और निर्माण का समय शामिल होता है। इसे एटॉमिक रूप से उपयोग (consume) करें। नवीनतम verifier पर वापस जाने के बजाय अज्ञात, डुप्लिकेट और समाप्त states को अस्वीकार करें।