बैकएंड इंटरव्यू: ट्रांजेक्शन ऑथराइजेशन के लिए आप OAuth RAR और DPoP को कैसे जोड़ेंगे?

प्रॉम्प्ट और दायरा

एक मोबाइल बैंकिंग क्लाइंट भुगतान API को कॉल करता है। उपयोगकर्ता किसी एक लाभार्थी को 500 USD के एकल ट्रांसफ़र को स्वीकृति दे सकता है। ऑथराइजेशन सर्वर को सहमति के दौरान लेन-देन का विवरण दिखाना चाहिए, और कॉपी किए गए एक्सेस टोकन को किसी अन्य क्लाइंट इंस्टेंस से पुनः उपयोग करने योग्य नहीं होना चाहिए। Demonstrating Proof of Possession (DPoP) के साथ OAuth 2.0 Rich Authorization Request (RAR) डिज़ाइन की व्याख्या करें, जिसमें टोकन जारी करना, रिसोर्स-सर्वर जाँच, रीप्ले हैंडलिंग, की (key) का खोना और सत्यापन शामिल हो।

यह बैकएंड सुरक्षा और API-कॉन्ट्रैक्ट से संबंधित प्रश्न है। सटीक मुद्रा, राशि और लाभार्थी साक्षात्कार के लिए मानी गई स्थितियाँ हैं, बाजार के तथ्य नहीं।

साक्षात्कारकर्ता क्या जांच रहा है

क्या आप इसमें अंतर कर पाते हैं कि उपयोगकर्ता ने किस बात के लिए सहमति दी है और एक एक्सेस टोकन क्या कॉल कर सकता है।
क्या आप जानते हैं कि RAR संरचित ऑथराइजेशन विवरण ले जाता है, जबकि DPoP टोकन को एक की (key) से बांधता है और प्रति अनुरोध पज़ेशन साबित करता है।
क्या प्रत्येक प्रवर्तन बिंदु (enforcement point) का नाम लिया गया है: ऑथराइजेशन सर्वर, टोकन एंडपॉइंट, रिसोर्स सर्वर और भुगतान लेजर।
क्या आप रीप्ले, डुप्लिकेट सबमिशन, की (key) के खोने और अस्पष्ट प्रदाता प्रतिक्रियाओं को नियंत्रित कर सकते हैं।
क्या रोलआउट और परीक्षण केवल JWT सिंटैक्स की जाँच करने के बजाय व्यावसायिक इनवेरिएंट (business invariant) को साबित करते हैं।

एक कमजोर उत्तर कहता है "राशि को एक स्कोप में डालें और JWT पर हस्ताक्षर करें।" एक मजबूत उत्तर लेन-देन के विवरण को संरचित रखता है, जारी किए गए टोकन को क्लाइंट की (key) से बांधता है, और अंतिम भुगतान स्टेट मशीन को आधिकारिक बनाता है।

पहले पूछे जाने वाले स्पष्टीकरण

क्या ऑथराइजेशन सर्वर ही भुगतान लेजर का स्वामी भी है? यदि नहीं, तो लेजर को कमिट के समय ऑथराइजेशन निर्णय की पुनः जाँच करनी चाहिए।
क्या एक ऑथराइजेशन ठीक एक ट्रांसफ़र के लिए मान्य है, या यह ट्रांसफ़र के एक सीमित सेट को ऑथराइज़ कर सकता है? RAR विवरण और टोकन का जीवनकाल इस सीमा पर निर्भर करता है।
क्या मोबाइल क्लाइंट रीइंस्टॉल के बाद भी हार्डवेयर-समर्थित की (key) को बनाए रख सकता है, और खोए हुए डिवाइस को कैसे रिवोक किया जाता है?
क्या रिसोर्स सर्वर को DPoP नॉन्स (nonce) की आवश्यकता प्राप्त होती है, और क्लॉक-स्क्यू (clock-skew) विंडो क्या स्वीकार्य है?
भुगतान प्रदाता पर टाइमआउट के बाद क्या होता है: क्या सिस्टम स्थिति की जानकारी ले सकता है, या इसे अज्ञात स्थिति रिकॉर्ड करनी होगी?

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

"मैं एक व्यापक स्कोप बनाने के बजाय सटीक ट्रांसफ़र को एक authorization_details ऑब्जेक्ट में रखूँगा। क्लाइंट एक की-पेयर (key pair) बनाता है और टोकन का अनुरोध करते समय DPoP प्रूफ भेजता है; ऑथराइजेशन सर्वर टोकन को उस पब्लिक की से बांधता है। रिसोर्स सर्वर एक्सेस टोकन, DPoP प्रूफ, मेथड, URI, टाइमस्टैम्प, नॉन्स और टोकन-की बाइंडिंग को मान्य करता है, फिर ऑथराइज़्ड ट्रांजेक्शन आइडेंटिफ़ायर को भुगतान लेजर को पास करता है। लेजर इसे आइडेम्पोटेंसी की के साथ एक बार स्वीकार करता है और एक टर्मिनल स्थिति रिकॉर्ड करता है। रीप्ले सुरक्षा, डिवाइस रिवोकेशन, प्रदाता टाइमआउट और ऑडिट साक्ष्य अलग-अलग नियंत्रण हैं, जिनका परीक्षण उनके संबंधित ओनर पर किया जाता है।"

चरण-दर-चरण समाधान

1. अनुरोधित कार्रवाई का मॉडल बनाएं

RAR एक संरचित authorization_details अनुरोध को परिभाषित करता है। ऑब्जेक्ट में एक पंजीकृत type, सटीक कार्रवाई, राशि, मुद्रा, गंतव्य पहचानकर्ता और एक लेन-देन संदर्भ होना चाहिए। ऑथराइजेशन सर्वर सहमति प्रस्तुत करने से पहले स्कीमा, खाते के स्वामित्व, सीमाओं और नीतियों को मान्य करता है। इसे उन्हीं कैनोनिकल मानों को प्रदर्शित करना चाहिए जिनका उपयोग लेजर द्वारा किया जाएगा; क्लाइंट द्वारा प्रदान किया गया लेबल पर्याप्त नहीं है।

json

{
  "type": "payment",
  "actions": ["transfer"],
  "amount": "500.00",
  "currency": "USD",
  "beneficiary_id": "b_123",
  "request_id": "rq_7f2"
}

ऑथराइजेशन परिणाम को सर्वर-स्वामित्व वाले ऑथराइजेशन रिकॉर्ड को संदर्भित करना चाहिए। किसी रिसोर्स सर्वर को अविश्वसनीय डिस्प्ले स्ट्रिंग से धन, मुद्रा या लाभार्थी का पुनर्निर्माण न करने दें।

2. टोकन को क्लाइंट की (key) से बांधें

क्लाइंट एक संरक्षित स्टोर में एक प्राइवेट की बनाता है और टोकन एंडपॉइंट पर DPoP प्रूफ JWT भेजता है। प्रूफ में HTTP मेथड, टारगेट URI, जारी होने का समय (issued-at time), एक अद्वितीय प्रूफ पहचानकर्ता और पब्लिक की शामिल होती है। ऑथराइजेशन सर्वर प्रूफ की जाँच करता है और एक टोकन जारी करता है जिसका कन्फर्मेशन क्लेम (confirmation claim) उस की (key) को संदर्भित करता है। इसलिए, प्राइवेट की के बिना कॉपी किया गया बियरर टोकन किसी संरक्षित अनुरोध के लिए अपर्याप्त होता है।

DPoP एप्लिकेशन-स्तरीय प्रेषक बाधा (sender constraint) है; यह TLS, सुरक्षित की स्टोरेज, ऑथराइजेशन नीति या डिवाइस रिवोकेशन की जगह नहीं लेता है। की (key) क्लाइंट इंस्टेंस के लिए एक प्रमाणक है, यह इस बात का प्रमाण नहीं है कि मानव ने किसी विशेष भुगतान को मंजूरी दी है।

3. प्रत्येक रिसोर्स अनुरोध को सत्यापित करें

क्लाइंट एक्सेस टोकन और एक नया DPoP प्रूफ दोनों भेजता है। रिसोर्स सर्वर सिग्नेचर, टोकन की समाप्ति, जारीकर्ता (issuer), ऑडियंस, कन्फर्मेशन थंबप्रिंट, मेथड, URI, क्लॉक विंडो, आवश्यकता पड़ने पर नॉन्स, और प्रूफ पहचानकर्ता रीप्ले कैश की जाँच करता है। यह किसी अन्य URI के लिए या अपनी रीप्ले विंडो के बाद पुन: उपयोग किए गए प्रूफ को अस्वीकार कर देता है। एक्सेस-टोकन बाइंडिंग और ऑथराइजेशन-विवरण लुकअप की एक साथ जाँच की जानी चाहिए; किसी भिन्न टोकन के लिए एक वैध प्रूफ पर्याप्त नहीं है।

4. लेजर को अंतिम प्राधिकारी बनाएं

रिसोर्स सर्वर एक भुगतान कमांड बनाता है जिसमें ऑथराइजेशन रिकॉर्ड ID, कैनोनिकल राशि और लाभार्थी का डाइजेस्ट, क्लाइंट इंस्टेंस ID और एक आइडेम्पोटेंसी की शामिल होती है। लेजर एक ही लेन-देन में कमांड की तुलना स्वीकृत रिकॉर्ड से करता है। यह केवल एक अप्रयुक्त ऑथराइजेशन को स्वीकार करता है, PENDING या COMMITTED लिखता है, और बदली हुई राशि, गंतव्य, समाप्त हो चुकी स्वीकृति या दूसरे टर्मिनल ट्रांज़िशन को अस्वीकार कर देता है। यदि कोई बाहरी प्रदाता टाइमआउट हो जाता है, तो UNKNOWN रिकॉर्ड करें और पुनः प्रयास करने से पहले स्थिति की जांच या मिलान (reconcile) करें; टाइमआउट यह साबित नहीं करता कि कोई शुल्क नहीं काटा गया।

5. पुनर्प्राप्ति और रिवोकेशन को संभालें

सीमित रीप्ले विंडो के लिए प्रूफ पहचानकर्ताओं को संग्रहीत करें और कैश को क्लाइंट और जारीकर्ता द्वारा सीमित करें। खोया हुआ डिवाइस केवल ब्राउज़र सत्र को ही नहीं, बल्कि की (key) या उसके ऑथराइजेशन रिकॉर्ड को रिवोक करता है। सहमति पेलोड हैश, प्रदर्शित मान, टोकन की थंबप्रिंट, रिसोर्स निर्णय, लेजर ट्रांज़िशन और ऑपरेटर कार्रवाई के लिए ऑडिट प्रविष्टियां रखें। प्राइवेट की और रॉ टोकन को छुपाएं (redact करें)। विफल रोलआउट पुराने, अलग से प्रबंधित फ़्लो को बनाए रखते हुए नए ऑथराइजेशन-विवरण प्रकार को अक्षम कर सकता है।

6. विकल्पों की तुलना करें

payments.write जैसे व्यापक स्कोप सरल हैं लेकिन एक राशि और एक लाभार्थी को व्यक्त नहीं कर सकते; लेजर को वैसे भी एक और विश्वसनीय ट्रांजेक्शन ऑथराइजेशन की आवश्यकता होगी। म्यूचुअल TLS टोकन को एक प्रमाणपत्र से बांध सकता है और नियंत्रित सर्वर क्लाइंट के लिए आकर्षक है, लेकिन मोबाइल डिवाइस प्रमाणपत्र जीवनचक्र और नेटवर्क टर्मिनेशन अधिक कठिन हैं। DPoP एप्लिकेशन-प्रबंधित कुंजियों और HTTP क्लाइंट के लिए उपयुक्त है, लेकिन नॉन्स, क्लॉक, रीप्ले-कैश और की-लॉस हैंडलिंग स्पष्ट कार्यान्वयन कार्य बन जाते हैं।

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

"मैं चार निर्णयों को अलग करूँगा। पहला, RAR सटीक राशि, मुद्रा, लाभार्थी और सर्वर अनुरोध ID के साथ एक टाइप्ड भुगतान ऑथराइजेशन ले जाता है; सहमति स्क्रीन कैनोनिकल मान प्रस्तुत करती है और ऑथराइजेशन सर्वर सीमाओं को मान्य करता है। दूसरा, मोबाइल क्लाइंट एक संरक्षित की (key) और DPoP प्रूफ का उपयोग करता है, और जारी किया गया टोकन उस की (key) से बंधा होता है। तीसरा, रिसोर्स सर्वर-स्वामित्व वाले ऑथराइजेशन रिकॉर्ड को लोड करने से पहले टोकन, प्रूफ, URI, समय, नॉन्स और प्रूफ रीप्ले को मान्य करता है। अंत में, भुगतान लेजर परमाणु रूप से (atomically) उस रिकॉर्ड की तुलना कमांड से करता है और एक आइडेम्पोटेंट टर्मिनल ट्रांज़िशन की अनुमति देता है। बिना की (key) के कॉपी किया गया टोकन, बदला हुआ लाभार्थी, डुप्लिकेट प्रूफ, या दूसरा सबमिशन अस्वीकार कर दिया जाता है। प्रदाता टाइमआउट UNKNOWN बन जाता है और उसका मिलान किया जाता है, कभी भी आँख बंद करके पुनः प्रयास नहीं किया जाता है। मैं अस्वीकृत रीप्ले, नॉन्स विफलताओं, ऑथराइजेशन विसंगतियों, डुप्लिकेट कमांड, अज्ञात परिणामों और रिवोकेशन प्रसार को मापूँगा, फिर रोलबैक स्विच के साथ नए RAR प्रकार को कैनरी (canary) रोलआउट करूँगा।"

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

राशि और लाभार्थी को स्कोप में डालना → स्कोप अनबाउंडेड स्ट्रिंग बन जाते हैं और टाइप्ड सत्यापन खो देते हैं → एक पंजीकृत authorization-details स्कीमा और सर्वर-स्वामित्व वाले रिकॉर्ड का उपयोग करें।
DPoP को मानवीय सहमति मानना → की (key) का होना यह साबित नहीं करता कि उपयोगकर्ता ने क्या स्वीकृत किया है → सहमति, टोकन बाइंडिंग और लेजर ऑथराइजेशन को अलग रखें।
केवल गेटवे पर DPoP को मान्य करना → आंतरिक कॉलर या वैकल्पिक रूट जाँच को बायपास कर सकते हैं → प्रत्येक रिसोर्स सीमा पर बाइंडिंग लागू करें और एक हस्ताक्षरित निर्णय ID पास करें।
प्रदाता टाइमआउट को एक नए भुगतान के रूप में पुनः प्रयास करना → पहला अनुरोध कमिट हो सकता है → स्थिति की जाँच करें, एक आइडेम्पोटेंसी की का उपयोग करें, और एक स्पष्ट UNKNOWN स्थिति बनाए रखें।
प्रूफ ID को हमेशा के लिए कैश करना → मेमोरी बढ़ती है और नीति परिवर्तन के बारे में विचार करना कठिन हो जाता है → प्रूफ के जीवनकाल और क्लॉक नीति से बंधी एक सीमित रीप्ले विंडो का उपयोग करें।

फॉलो-अप और उत्तर

क्या होगा यदि हमलावर एक्सेस टोकन और DPoP प्रूफ दोनों चुरा लेता है?

प्रूफ पहचानकर्ता के पुनः उपयोग को अस्वीकार करें और इसके मेथड, URI, समय और नॉन्स प्रतिबंधों को लागू करें। प्रूफ का जीवनकाल छोटा रखें और प्रति अनुरोध एक नए प्रूफ की आवश्यकता रखें। यदि प्राइवेट की से भी समझौता हो गया है, तो की बाइंडिंग और ऑथराइजेशन रिकॉर्ड को रिवोक करें; DPoP अपने आप से किसी से समझौता की गई की (key) को पुनर्प्राप्त नहीं कर सकता है।

JWT स्कोप में भुगतान को एन्कोड क्यों नहीं करते?

स्कोप मोटे तौर पर अनुमति के लिए उपयोगी है, लेकिन पैसे के ट्रांसफ़र के लिए टाइप्ड फ़ील्ड, सत्यापन, डिस्प्ले और एक स्थिर सर्वर रिकॉर्ड की आवश्यकता होती है। RAR और लेजर द्वारा सटीक ट्रांजेक्शन को लागू करते हुए स्कोप स्ट्रिंग एक व्यापक क्षमता के रूप में बनी रह सकती है।

यदि रिसोर्स सर्वर और ऑथराइजेशन सर्वर असहमत हों तो क्या होगा?

सर्वर-स्वामित्व वाली ऑथराइजेशन ID और संस्करणित रिकॉर्ड का उपयोग करें। रिसोर्स सर्वर को तब फेल-क्लोज्ड (fail closed) होना चाहिए जब उच्च-जोखिम वाली कार्रवाई के लिए रिकॉर्ड अनुपलब्ध हो या उसका संस्करण पुराना हो। लेजर अपने ट्रांजेक्शन में संस्करण की पुनः जाँच करता है, इसलिए पुराना कैश्ड निर्णय किसी बदले हुए भुगतान को कमिट नहीं कर सकता है।

क्या DPoP सभी रीप्ले को रोकता है?

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