auth.md — एजेंट द्वारा उपयोगकर्ता की ओर से साइन-अप कराने के लिए ओपन प्रोटोकॉल

 (workos.com)
6 पॉइंट द्वारा xguru 5 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • हर सेवा अपने डोमेन रूट पर होस्ट करने वाली auth.md फ़ाइल के लिए एक मानक
  • यह एजेंट को बताता है कि उपयोगकर्ता की ओर से रजिस्ट्रेशन कैसे करना है, ताकि अलग साइन-अप फ़ॉर्म के बिना एजेंट उपयोगकर्ता को रजिस्टर कर सके
  • फ़ाइल में समर्थित flow, उपलब्ध scope, और सेवा में रजिस्ट्रेशन की विधि शामिल होती है
  • यह तीन पक्षों से मिलकर बना है
    • agent: उपयोगकर्ता की ओर से काम करने वाला पक्ष
    • agent provider: पहचान assertion ID-JAG जारी करने वाला IdP
    • service: assertion स्वीकार कर credentials जारी करने वाला पक्ष
  • एजेंट auth.md लाता है, समर्थित flow चुनता है, फिर verified identity assertion प्रस्तुत करता है या उपयोगकर्ता के लिए कोड पुष्टि claim करता है
  • रजिस्ट्रेशन के तरीकों को मार्केटिंग में दो तरह से पेश किया जाता है, लेकिन इम्प्लीमेंटेशन के स्तर पर anonymous सहित तीन हैं
    • Agent verified: एजेंट का IdP उपयोगकर्ता की पुष्टि करता है, मानव हस्तक्षेप नहीं
    • User claimed: provider की ज़रूरत नहीं, एजेंट द्वारा दिखाया गया कोड उपयोगकर्ता लॉगिन के बाद पुष्टि करता है। RFC 8628 शैली claim ceremony (device flow तरीका) का उपयोग
    • Anonymous Registration: एजेंट पहले pre-claim scope के साथ काम करता है, फिर उपयोगकर्ता स्वामित्व दावा करने पर post-claim token में अपग्रेड हो जाता है
    • ज़्यादातर ऐप्स दोनों तरीके सपोर्ट करेंगे, और एजेंट स्थिति के अनुसार चुन सकता है
  • एजेंट को उपयोगकर्ता से बंधा हुआ scoped access token जारी किया जाता है, जिसकी अवधि छोटी होती है और जिसे रद्द किया जा सकता है
  • यह मानक OAuth के ऊपर जारी होता है, इसलिए मौजूदा API auth को वैसे ही दोबारा इस्तेमाल किया जा सकता है
    • ID-JAG जारी करना → RFC 7523 JWT-bearer grant से access_token एक्सचेंज, /.well-known/oauth-authorization-server discovery के साथ काम करता है
  • WorkOS द्वारा लिखा गया, लेकिन WorkOS infrastructure पर निर्भर नहीं रहने वाला ओपन प्रोटोकॉल
    • मौजूदा OAuth standards (Protected Resource Metadata, ID-JAG) को मिलाकर अकाउंट के बिना publish और read संभव
  • ऐप/सेवा यह सीधे नियंत्रित कर सकती है कि कौन-सा flow स्वीकार करना है और कौन-से credentials जारी करने हैं
  • केवल spec ही नहीं, बल्कि agent provider और service दोनों पक्षों के sample implementation तथा skill manifest की भूमिका वाला AUTH.md फ़ाइल भी दिया गया है, इसलिए इसे वास्तव में चलाकर देखा जा सकता है
  • Cloudflare, Firecrawl, Resend, monday.com जैसी कई सेवाओं ने इसे पहले ही अपनाया है
  • MIT लाइसेंस

संबंधित पढ़ाई

2 टिप्पणियां

 
bichi 2 시간 전

यह AUTH.md क्यों नहीं है?
 
laeyoung 3 시간 전

Firecrawl, Resend का auth.md।

Cloudflare प्रोटोकॉल परिचय पेज पर पहले लागू किए गए उदाहरण के रूप में दिखता है, लेकिन क्लिक करके अंदर जाने पर not found :( दिखाई देता है।