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

• 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 नहीं किया जा सका, इसलिए संबंधित सामग्री हटा दी गई

[rikko]

सरकारी 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 जैसी सुविधाएँ आसान होने पर भी इस्तेमाल नहीं करता...