OAuth प्रदाताओं के नाम एक पत्र

 (pilcrowonpaper.com)
1 पॉइंट द्वारा GN⁺ 2024-12-13 | 2 टिप्पणियां | WhatsApp पर शेयर करें

  • OAuth प्रदाताओं के नाम एक पत्र

    • GitHub

      • token endpoint त्रुटि होने पर भी 200 status code लौटाता है
      • त्रुटि response में 400 या 401 status code का उपयोग होना चाहिए

    • Facebook

      • token endpoint custom error response लौटाता है
      • यह error field वाला JSON object होना चाहिए

    • TikTok

      • server client_id के बजाय client_key parameter का उपयोग करता है
      • specification से हटने का कोई कारण नहीं है

    • Strava

      • server scope parameter में comma-separated list का उपयोग करता है
      • यह space-separated list होनी चाहिए

    • Naver

      • server token expiration time को string के रूप में लौटाता है
      • यह specification compliance से आगे की समस्या है

    • विभिन्न OAuth प्रदाता

      • client authentication के लिए client_secret parameter के बजाय HTTP Basic authentication को support करना चाहिए
      • OAuth 2.1 standard में HTTP Basic authentication optional है, लेकिन PKCE आवश्यक होने के बावजूद अधिकांश प्रदाता इसका उपयोग नहीं करते

    • AWS

      • OAuth client library के साथ उपयोग करते समय कई bug reports मिले, लेकिन समस्या को reproduce नहीं किया जा सका, इसलिए संबंधित सामग्री हटा दी गई

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

2 टिप्पणियां

 
rikko 2024-12-13

सरकारी public service project बनाते समय मुझे OAuth (OIDC) फीचर implement करने में ही पूरा 1 महीना लग गया था...

बाहरी library इस्तेमाल नहीं कर सकते थे, इसलिए सब कुछ एक-एक करके खुद implement करना पड़ा, लेकिन OAuth standard को ठीक से follow करने वाले Kakao या Google के अलावा कोई नहीं था...

Naver का तो स्तर ऐसा था कि बस login हो जाए तो कोई समस्या नहीं, और समझ नहीं आता था कि इसे इस्तेमाल भी करना चाहिए या नहीं; Apple के मामले में तो अब सोचने पर यह भी याद नहीं कि मैंने उसे कैसे implement किया था, क्योंकि उसमें मौजूदा OAuth source की तुलना में 3 गुना से ज़्यादा implementation code चाहिए था.

ऊपर मुख्य लेख की तरह कुछ मामलों में response code पूरी तरह बिखरा हुआ होता था, और हद तो तब थी जब 418 (I'm a teapot) लौटाने वाले provider भी थे.
ऐसे अनुभवों की वजह से मैं social login जैसी सुविधाएँ आसान होने पर भी इस्तेमाल नहीं करता...
 
GN⁺ 2024-12-13
Hacker News राय

  • एक उपयोगकर्ता ने अपनी कंपनी के इंट्रानेट में OAuth सर्वर लागू किया। दूसरी टीम ने आधिकारिक स्पेसिफिकेशन का पालन किए बिना login implementation की मांग की, और आखिरकार उन्हें OAuth का एक अनौपचारिक variant बनाना पड़ा

  • OAuth इस्तेमाल करते समय, जब कई provider और email signup option होते हैं, तो कभी-कभी यह याद नहीं रहता कि पहले किस तरीके से login किया था, और गलती से नया account बन जाता है

  • एक साल पहले 100 लोकप्रिय API के लिए OAuth लागू किया था, और अनुभव OP के बताए गए अनुभव जैसा ही था

  • कई provider prompt=select_account को support नहीं करते, या उपयोगकर्ता से यह चुनने के लिए नहीं कहते कि किस account से login करना है। यह OIDC में खास तौर पर समस्या है

  • AWS से जुड़ी bug report मिली थी, लेकिन उसे reproduce नहीं किया जा सका, इसलिए पोस्ट से वह सेक्शन हटा दिया गया। फिर भी, वह सामान्य problem checklist के रूप में उपयोगी हो सकता था

  • अगर कोई आधिकारिक test suite हो, तो वह open standard implementation में मदद करेगा। स्पेसिफिकेशन को ट्रैक करना मुश्किल होता है, इसलिए validate करने लायक test suite उपयोगी होगा

  • Facebook की समस्या ऐसी लगती है कि उसने मौजूदा service framework का उपयोग करके OAuth2 को code किया, लेकिन उसे स्पेसिफिकेशन के मुताबिक नहीं बना पाया। यह scripting की आम समस्याओं जैसा है

  • कुछ provider ने स्पेसिफिकेशन का पालन नहीं किया और refresh token के लिए अलग endpoint चुना

  • OIDC/OAuth provider से SCIM support ठीक से करने और सिस्टम को "API-first" सोच के साथ design करने का अनुरोध किया गया। GNAP पर जाने से पहले इस फैसले पर फिर से विचार करने की जरूरत है