प्रॉम्प्ट और दायरा
यह एक OAuth प्रोटोकॉल और सुरक्षा-डिज़ाइन समस्या है। RFC 8628 स्मार्ट टीवी, मीडिया कंसोल, प्रिंटर और इसी तरह के उन उपकरणों को लक्षित करता है जो आसानी से टेक्स्ट दर्ज नहीं कर सकते या ब्राउज़र नहीं चला सकते। डिवाइस एक device_code और user_code का अनुरोध करता है; यूज़र एक अलग ब्राउज़र पर साइन इन करता है और ऑथराइज़ करता है; मूल डिवाइस टोकन एंडपॉइंट को पोल करता है। ऐसे डिवाइस आमतौर पर पब्लिक क्लाइंट होते हैं और फर्मवेयर में लंबे समय तक रहने वाले क्लाइंट सीक्रेट को छिपा नहीं सकते हैं। यह अभ्यास उन नेटिव ऐप्स के लिए ऑथराइजेशन-कोड फ़्लो को प्रतिस्थापित नहीं करता है जो सिस्टम ब्राउज़र का उपयोग कर सकते हैं।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
- डिवाइस कोड, यूज़र कोड, वेरिफिकेशन URI, एक्सेस टोकन और रिफ्रेश टोकन के लाइफ़टाइम में अंतर करना।
authorization_pending,slow_down,expired_token, औरaccess_deniedको स्टेट्स में मैप करना।- बाउंडेड पोलिंग, बैकऑफ, आइडेम्पोटेंसी और समवर्ती (concurrency) सुरक्षा डिज़ाइन करना।
- यूज़र-कोड फ़िशिंग, डिवाइस प्रतिरूपण (impersonation), ब्रूट-फ़ोर्स अनुमान और पब्लिक-क्लाइंट जोखिमों को पहचानना।
पहले पूछे जाने वाले स्पष्टीकरण
पुष्टि करें कि क्या डिवाइस एक URI और कोड प्रदर्शित कर सकता है, HTTPS अनुरोध कर सकता है, और एक विश्वसनीय घड़ी बनाए रख सकता है, और क्या ऑथराइजेशन सर्वर OIDC साइन-इन का समर्थन करता है। अनुरोधित संसाधनों, डिवाइस बाइंडिंग, कोड लाइफ़टाइम और पोलिंग अंतराल कौन निर्धारित करता है, और क्या रद्दीकरण (cancellation) आवश्यक है, इसे स्पष्ट करें। यदि डिवाइस में पहले से ही एक सिस्टम ब्राउज़र है, तो Device Flow को बाध्य करने के बजाय RFC 8252 ऑथराइजेशन-कोड फ़्लो को प्राथमिकता दें।
30-सेकंड का उत्तर
दो एंडपॉइंट लागू करें। डिवाइस-ऑथराइजेशन एंडपॉइंट एक अल्पकालिक device_code, मानव द्वारा दर्ज किया जाने वाला user_code, verification_uri, समाप्ति और न्यूनतम अंतराल लौटाता है। टोकन एंडपॉइंट केवल डिवाइस कोड स्वीकार करता है और टोकन या मानक त्रुटियां लौटाता है। डिवाइस कोड का हैश, स्थिति, क्लाइंट और समाप्ति संग्रहीत करें। सर्वर द्वारा प्रदान किए गए अंतराल पर पोल करें: authorization_pending पर जारी रखें, slow_down पर अंतराल बढ़ाएं, और सफलता, समाप्ति, अस्वीकृति या स्थायी अमान्यता पर रुकें। फ़िशिंग को कम करने के लिए यूज़र पेज पर डिवाइस की जानकारी दिखाएं।
चरण-दर-चरण समाधान
1. प्रतिभागियों और एक ऑथराइजेशन सत्र का मॉडल बनाएं
प्रतिभागी विवश डिवाइस, ऑथराइजेशन सर्वर, यूज़र ब्राउज़र और रिसोर्स सर्वर हैं। डिवाइस-ऑथराइजेशन एंडपॉइंट उच्च-एंट्रॉपी device_code, दर्ज करने में आसान user_code, क्लाइंट, अनुरोधित स्कोप, निर्माण समय, समाप्ति और पोलिंग स्थिति के साथ एक सत्र बनाता है। केवल डिवाइस कोड का वन-वे डाइजेस्ट संग्रहीत करें ताकि डेटाबेस रीड सीधे टोकन जारी न कर सके; यूज़र कोड को अलग से इंडेक्स करें और प्रयासों को सीमित करें।
2. डिवाइस-ऑथराइजेशन प्रतिक्रिया डिज़ाइन करें
कम से कम device_code, user_code, verification_uri, expires_in, और interval लौटाएं। verification_uri_complete एक सुविधाजनक लिंक प्रदान कर सकता है, लेकिन डिवाइस और यूज़र पेज पर समान शॉर्ट कोड प्रदर्शित करें और यूज़र से अपने सामने मौजूद डिवाइस की पुष्टि करने के लिए कहें। कोड को लॉग, एनालिटिक्स और स्क्रीनशॉट से सुरक्षित रखें। सर्वर को इस प्रतिक्रिया में एक्सेस टोकन शामिल नहीं करना चाहिए।
3. यूज़र इंटरैक्शन और बाइंडिंग संभालें
वेरिफिकेशन URI खोलने के बाद, यूज़र साइन इन करता है और क्लाइंट का नाम, अनुरोधित स्कोप और डिवाइस की जानकारी देखता है। सहमति पृष्ठ पर यूज़र से पुष्टि करानी चाहिए कि डिवाइस उनका है, जिससे किसी हमलावर के डिवाइस के ऑथराइजेशन को कम किया जा सके। स्वीकृति सत्र को AUTHORIZED में बदल देती है; यह ब्राउज़र के माध्यम से डिवाइस पर टोकन नहीं भेजती है। अस्वीकृति एक टर्मिनल DENIED स्थिति है जिसे अगला पोल स्पष्ट रूप से रिपोर्ट करता है।
4. टोकन-एंडपॉइंट स्टेट मशीन को परिभाषित करें
टोकन एंडपॉइंट मानक त्रुटियों के साथ डिवाइस की स्थिति को संचालित करता है:
poll(device_code):
session = lookup(hash(device_code))
if session is missing: return invalid_grant
if now >= session.expiresAt: return expired_token
if session.status == DENIED: return access_denied
if session.status != AUTHORIZED: return authorization_pending
atomically mark CONSUMED
return issueAccessAndRefreshTokens(session)एक डिवाइस कोड का सफल रिडेम्पशन परमाणु (atomic) होना चाहिए ताकि दो डिवाइस थ्रेड दो टोकन सेट प्राप्त न कर सकें। यदि कोई कोड एकल-उपयोग है, तो दोहराया गया अनुरोध invalid_grant या प्रोटोकॉल की उपभोग की गई त्रुटि लौटाता है; एक असफल पुनप्र्रयास को एक नया ऑथराइजेशन सत्र नहीं बनाना चाहिए।
5. पोलिंग बैकऑफ और सर्वर सुरक्षा लागू करें
डिवाइस को प्रतिक्रिया के interval से पहले पोल नहीं करना चाहिए। authorization_pending के बाद उस अंतराल को बनाए रखें; slow_down के बाद, इसे कम से कम 5 सेकंड बढ़ाएं। डिवाइस पर कुल समय सीमा, नेटवर्क टाइमआउट और जिटर जोड़ें। सर्वर पर डिवाइस कोड, क्लाइंट और IP द्वारा दर-सीमित (rate-limit) करें। टोकन प्रतिक्रियाओं को कैशिंग से रोकना चाहिए ताकि मध्यस्थ स्थिति को फिर से न चला सकें; लोड के दौरान, प्रति पोल एक महंगा बैकग्राउंड टास्क बनाने के बजाय पुनः प्रयास करने योग्य त्रुटि लौटाएं।
6. समाप्ति, रद्दीकरण और पुनर्प्राप्ति को संभालें
expired_token, access_denied, और स्थायी invalid_grant को टर्मिनल के रूप में मानें। स्थानीय डिवाइस कोड साफ़ करें और पोलिंग बंद करें। डिवाइस रद्द करने की कार्रवाई सत्र को CANCELLED के रूप में चिह्नित करती है; बाद के अनुरोध इसे पुनर्जीवित नहीं कर सकते। नेटवर्क आउटेज पर, कई सत्र बनाने के बजाय जो गलत डिवाइस को ऑथराइज़ कर सकते हैं, समय सीमा बनाए रखें और उसी कोड को फिर से शुरू करें। रीबूट के बाद, पुनरारंभ करें और यूज़र को बताएं कि क्या डिवाइस सत्र स्थिति को सुरक्षित रूप से बनाए नहीं रख सकता है।
7. पब्लिक क्लाइंट को सुरक्षित करें और फ़िशिंग का विरोध करें
मान लें कि डिवाइस क्लाइंट सीक्रेट की सुरक्षा नहीं कर सकता है। स्कोप को न्यूनतम करें, और रिफ्रेश टोकन को घुमाएं (rotate) और रद्द (revoke) करें। यूज़र कोड को दर्ज करने के लिए पर्याप्त छोटा बनाएं लेकिन ऑनलाइन अनुमान का विरोध करने के लिए पर्याप्त यादृच्छिक बनाएं; कोड और IP द्वारा विफल प्रयासों को दर-सीमित करें। डिवाइस का नाम, मॉडल या वन-टाइम कोड दिखाएं और यूज़र से स्क्रीन के साथ इसकी तुलना करने के लिए कहें। लॉग में केवल एक सत्र ID, परिणाम और हैश किए गए पहचानकर्ता होते हैं, कभी भी कच्चा डिवाइस कोड या टोकन नहीं होते हैं।
8. फ़्लो को इंस्ट्रूमेंट और टेस्ट करें
डिवाइस-ऑथराइजेशन निर्माण, पूर्णता, पूर्णता का समय, प्रति सत्र पोल, slow_down दर, समाप्ति और अस्वीकृति, और टोकन-रिडेम्पशन रेस को मापें। डुप्लिकेट रिडेम्पशन, टाइमआउट, क्लॉक स्क्यू, नेटवर्क पुनप्र्रयास, अनुमान, समवर्ती पोल, यूज़र अस्वीकृति, सर्वर रीस्टार्ट और थ्रॉटलिंग का परीक्षण करें। एक एंड-टू-एंड परीक्षण को यह साबित करना चाहिए कि स्वीकृत डिवाइस और अंतिम टोकन सत्र मेल खाते हैं; स्वतंत्र रूप से 200 लौटाने वाले दो एंडपॉइंट अपर्याप्त हैं।
मॉडल उत्तर
मैं एक बार उपयोग होने वाला RFC 8628 सत्र बनाऊंगा। डिवाइस एंडपॉइंट एक उच्च-एंट्रॉपी device_code, लघु यूज़र कोड, वेरिफिकेशन URI, समाप्ति और न्यूनतम पोलिंग अंतराल लौटाता है; सर्वर एक हैशेड कोड और स्पष्ट स्थिति संग्रहीत करता है। यूज़र फ़ोन पर साइन इन करता है, क्लाइंट, स्कोप और डिवाइस जानकारी की समीक्षा करता है और स्वीकृत करता है। टोकन एंडपॉइंट केवल डिवाइस कोड स्वीकार करता है: authorization_pending पर जारी रखें, slow_down पर कम से कम 5 सेकंड जोड़ें, और समाप्ति, अस्वीकृति या स्थायी अमान्यता पर समाप्त करें। कोड का परमाणु रूप से उपभोग करें ताकि समवर्ती पोल दो टोकन सेट जारी न कर सकें। डिवाइस को एक पब्लिक क्लाइंट के रूप में मानें, स्कोप को न्यूनतम करें, रिफ्रेश टोकन को घुमाएं, अनुमान को सीमित करें, और यूज़र से दोनों स्क्रीन पर कोड की तुलना करने के लिए कहें। मेट्रिक्स और परीक्षण फ़्लो बाइंडिंग, बैकऑफ, रिकवरी और फ़िशिंग सीमाओं को कवर करते हैं।
सामान्य गलतियाँ
- डिवाइस कोड को मानव द्वारा दर्ज किए जाने वाले कोड के रूप में मानना और UI या लॉग में एक उच्च-मूल्य वाले क्रेडेंशियल को उजागर करना।
slow_downको अनदेखा करना और एक निश्चित उच्च दर पर टोकन एंडपॉइंट को पोल करना।- समाप्ति और अस्वीकृति सहित प्रत्येक त्रुटि को हमेशा के लिए पुन: प्रयास करना।
- यह दिखावा करना कि एक स्थिर डिवाइस सीक्रेट एक पब्लिक क्लाइंट को गोपनीय बना देता है।
- स्वीकृति के बाद सीधे ब्राउज़र URL या पेज स्क्रिप्ट के माध्यम से एक्सेस टोकन भेजना।
- डिवाइस कोड का परमाणु रूप से उपभोग करने में विफल होना और कई रिफ्रेश टोकन जारी करना।
- यह साबित किए बिना अलग-अलग पोलिंग एंडपॉइंट का परीक्षण करना कि स्वीकृत डिवाइस टोकन सत्र से मेल खाता है।
फॉलो-अप प्रश्न
आप यूज़र-कोड की लंबाई और लाइफ़टाइम कैसे चुनते हैं?
प्रविष्टि सुविधा, ऑनलाइन-अनुमान लागत और पूर्णता समय को संतुलित करें। अस्पष्ट वर्णों से बचें, विफल प्रयासों और कुल दर को सीमित करें, और लाइफ़टाइम को इतना लंबा बनाएं कि यूज़र एक असीमित फ़िशिंग विंडो बनाए बिना फ़ोन ला सके, साइन इन कर सके और डिवाइस की पुष्टि कर सके। खतरे के मॉडल और देखे गए पूर्णता समय के साथ संख्याओं को कैलिब्रेट करें।
आप किसी दुर्भावनापूर्ण क्लाइंट को सभी सत्रों को भरने से कैसे रोकते हैं?
क्लाइंट पंजीकरण, IP, डिवाइस फ़िंगरप्रिंट और खाते द्वारा निर्माण को दर-सीमित करें; प्रति प्रिंसिपल अधूरे सत्रों को सीमित करें और समाप्त हो चुके सत्रों को एसिंक्रोनस रूप से साफ़ करें। सत्र बनाने से पहले क्लाइंट और स्कोप को मान्य करें। टोकन एंडपॉइंट पर कचरा डिवाइस-कोड क्लीनअप दबाव को स्थानांतरित न करें।
स्वीकृति के बाद एक ऑफ़लाइन डिवाइस कैसे पुनर्प्राप्त होता है?
सत्र को समाप्ति तक रखें ताकि डिवाइस पुन: कनेक्ट होने के बाद उसी कोड को पोल कर सके। या तो टोकन सेट या टर्मिनल स्थिति लौटाएं। रिडेम्पशन हैंडलिंग को आइडेम्पोटेंट बनाएं ताकि खोई हुई प्रतिक्रिया दूसरा उपभोग न करे। समाप्ति के बाद, एक नए कोड के साथ पुनरारंभ करें और यूज़र को सूचित करें।
verification_uri_complete के जोखिम क्या हैं?
एक लिंक में यूज़र कोड डालने से टाइपिंग कम हो जाती है लेकिन लिंक लीकेज और रिमोट-फ़िशिंग जोखिम बढ़ जाता है। फिर भी शॉर्ट कोड प्रदर्शित करें और यूज़र से डिवाइस स्क्रीन के साथ इसकी तुलना करने के लिए कहें। एनालिटिक्स, Referer हेडर, इतिहास या तीसरे पक्ष के रीडायरेक्ट के लिए पूरा लिंक उजागर न करें। इसे केवल तभी पेश करें जब डिवाइस क्षमता और खतरे का मॉडल इसकी अनुमति दे।
एक्सेस टोकन को फ़ोन से डिवाइस पर स्थानांतरित क्यों नहीं किया जाता है?
क्रॉस-डिवाइस टोकन स्थानांतरण ब्राउज़र, QR कोड, क्लिपबोर्ड और मध्यवर्ती पृष्ठों के माध्यम से जोखिम को बढ़ाता है, और यह साबित करना कठिन है कि प्राप्तकर्ता सही डिवाइस है। Device Flow डिवाइस को TLS पर अपने स्वयं के कोड को भुनाने की अनुमति देता है; यूज़र पेज केवल सर्वर स्थिति बदलता है। यदि उत्पाद की आवश्यकता हो तो अलग से प्रमाणित नियर-फ़ील्ड चैनल जोड़ें।
आप कैसे सत्यापित करते हैं कि पोलिंग सही ढंग से बैक ऑफ हो रही है?
सत्र-स्तरीय पोल संख्या, अंतराल वितरण, slow_down के बाद वास्तविक अंतराल, टर्मिनल विलंबता और क्लाइंट-एग्रीगेटेड विफलताओं को रिकॉर्ड करें। नियंत्रित परीक्षणों में बार-बार पोल इंजेक्ट करें और सत्यापित करें कि slow_down बिना किसी सिंक्रनाइज़ किए गए तूफान के क्लाइंट अंतराल को कम से कम 5 सेकंड बढ़ा देता है। वैश्विक अंतराल को शिथिल करने के बजाय अपमानजनक क्लाइंट को अलग करें।