डेवलपर्स के लिए ओऑथ २.०: ऑथराइज़ेशन कोड, पीकेसीई, टोकन और आम बग

ओऑथ २.० वह प्रोटोकॉल है जो ज़्यादातर ऐप तब इस्तेमाल करते हैं जब यूज़र कहता है "इस ऐप को मेरा कैलेंडर पढ़ने दो" बिना पासवर्ड सौंपे। टीमें अब भी टूटे इम्प्लीमेंटेशन शिप करती हैं: एसपीए पर पीकेसीई नहीं, क्वेरी स्ट्रिंग में टोकन, एमवीपी के नाम पर state छोड़ दिया, रिफ़्रेश टोकन को सेशन कुकी जैसा स्टोर किया, और २०१८ के सैंपल से इम्प्लिसिट फ़्लो।

यह पोस्ट ऑथराइज़ेशन कोड + पीकेसीई, रोज़ छूने वाले टोकन प्रकार, और कोड रिव्यू व इंसिडेंट में आने वाले बग का व्यावहारिक नक्शा है।

ओऑथ ऑथराइज़ेशन है (डेलिगेटेड ऐक्सेस)। ऑथेंटिकेशन ("यह यूज़र कौन है?") आमतौर पर ऊपर ओपनआईडी कनेक्ट होता है। आप बिना ओआईडीसी के ओऑथ लागू कर सकते हैं। जब स्टैंडर्ड स्टैक मौजूद हो तो अपना लॉगिन प्रोटोकॉल मत गढ़ें।

चार भूमिकाएँ (नाम साफ़ रखें)

भूमिका	कौन	काम
रिसोर्स ओनर	यूज़र (या सर्विस अकाउंट)	सुरक्षित डेटा पर ऐक्सेस देता है
क्लाइंट	आपकी ऐप (वेब, मोबाइल, बैकएंड, सीएलआई)	टोकन माँगती है और एपीआई कॉल करती है
ऑथराइज़ेशन सर्वर	आइडेंटिटी प्रोवाइडर (ऑथज़ीरो, ओक्टा, कॉग्निटो, कीक्लोक, आपका आईडीपी)	यूज़र को ऑथेंटिकेट करता है, टोकन जारी करता है
रिसोर्स सर्वर	वह एपीआई जहाँ डेटा है	ऐक्सेस टोकन स्वीकार करता है और स्कोप लागू करता है

उलझन तब शुरू होती है जब एक ही प्रोडक्ट क्लाइंट और रिसोर्स सर्वर दोनों हो, या जब बीएफएफ (बैकएंड-फ़ॉर-फ़्रंटएंड) क्लाइंट हो और एसपीए न हो। लाइब्रेरी ट्यूटोरियल कॉपी करने से पहले बक्से खींचें।

कॉन्फ़िडेंशियल क्लाइंट क्लाइंट सीक्रेट रख सकते हैं (सर्वर-साइड वेब ऐप, कई बीएफएफ)। पब्लिक क्लाइंट नहीं रख सकते (नेटिव ऐप, शुद्ध ब्राउज़र एसपीए)। पब्लिक क्लाइंट को ऐसे सीक्रेट पर भरोसा नहीं करना चाहिए जो बाइनरी या जावास्क्रिप्ट बंडल में सफ़र करे।

"बस पासवर्ड भेज दो" क्यों नहीं?

पासवर्ड साझा करना प्रोडक्ट और सुरक्षा दोनों में फेल होता है:

१. थर्ड-पार्टी ऐप यूज़र का पासवर्ड सीख लेती है (आपकी सर्विस, गूगल, गिटहब आदि के लिए)। २. आप सीमित ऐक्सेस नहीं दे सकते (कैलेंडर पढ़ो, मेल मिटाओ नहीं)। ३. पासवर्ड रीसेट किए बिना एक ऐप रिवोक नहीं कर सकते। ४. किन ऐप के पास ऐक्सेस है, ऑडिट नहीं कर सकते।

ओऑथ स्कोप्ड, रिवोकेबल क्रेडेंशियल (टोकन) जारी करता है जो पासवर्ड नहीं हैं।

ऑथराइज़ेशन कोड फ़्लो (डिफ़ॉल्ट)

ऑथराइज़ेशन कोड फ़्लो ओऑथ २.० में यूज़र-फेसिंग ऐप का मुख्य रास्ता है, और ओऑथ २.१ में वही इंटरैक्टिव फ़्लो रखना चाहते हैं।

ऊपर से:

१. क्लाइंट यूज़र को ऑथराइज़ेशन सर्वर के /authorize एंडपॉइंट पर भेजता है: client_id, redirect_uri, scope, response_type=code, state, और (पीकेसीई के साथ) code_challenge + code_challenge_method। २. यूज़र ऑथेंटिकेट करता है और सहमति देता है। ३. ऑथराइज़ेशन सर्वर redirect_uri पर वापस रीडायरेक्ट करता है: छोटा जीवन वाला code और वही state। ४. क्लाइंट code (पीकेसीई के लिए code_verifier, कॉन्फ़िडेंशियल हो तो client_secret) को टोकन एंडपॉइंट पर बैक चैनल से बदलता है। ५. टोकन एंडपॉइंट access_token लौटाता है, अक्सर refresh_token, और (ओआईडीसी के साथ) id_token।

ब्राउज़र रीडायरेक्ट में कोड देखता है, ऐक्सेस टोकन नहीं। यही मक़सद है: क़ीमती टोकन उस अनुरोध पर मिलता है जो ब्राउज़र इतिहास, रेफ़रर हेडर, या बिचौलिए लॉग में फ्रैगमेंट/क्वेरी टोकन की तरह नहीं बैठता।

ऑथराइज़ यूआरएल का न्यूनतम आकार

GET /authorize?
  response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
  &scope=openid%20profile%20calendar.read
  &state=RANDOM_CSRF_OPAQUE
  &code_challenge=BASE64URL_SHA256_OF_VERIFIER
  &code_challenge_method=S256

टोकन एक्सचेंज का आकार

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&code=THE_CODE
&redirect_uri=https%3A%2F%2Fapp.example.com%2Fcallback
&client_id=YOUR_CLIENT_ID
&code_verifier=THE_ORIGINAL_VERIFIER

कॉन्फ़िडेंशियल क्लाइंट ऑथेंटिकेशन भी भेजते हैं (क्लाइंट आईडी/सीक्रेट के साथ एचटीटीपी बेसिक, या रजिस्ट्रेशन के अनुसार client_secret_post)। टोकन अनुरोध पर redirect_uri वही होना चाहिए जो कोड लेने में इस्तेमाल हुआ।

पीकेसीई: ऑथराइज़ेशन कोड इंटरसेप्शन रोकें

पीकेसीई (प्रूफ़ की फ़ॉर कोड एक्सचेंज, आरएफ़सी ७६३६) टोकन अनुरोध को उस क्लाइंट से बाँधता है जिसने ऑथराइज़ शुरू किया।

कैसे चलता है:

१. क्लाइंट ऊँची एंट्रॉपी वाला code_verifier बनाता है (४३-१२८ वर्ण, अनरिज़र्व्ड यूआरएल कैरेक्टर सेट)। २. विधि S256 हो तो code_challenge = BASE64URL(SHA256(code_verifier))। ३. ऑथराइज़ अनुरोध में सिर्फ़ चैलेंज (और विधि) जाती है। ४. टोकन अनुरोध में मूल वेरिफ़ायर जाता है। ५. ऑथराइज़ेशन सर्वर वेरिफ़ायर हैश करके स्टोर किए चैलेंज से मिलाता है।

अगर हमलावर रीडायरेक्ट चुरा ले (मोबाइल पर कस्टम यूआरएल स्कीम, गलत कॉन्फ़िग ऐप, लीक लॉग), फिर भी उसके पास वेरिफ़ायर नहीं होता जो वैध क्लाइंट से बाहर नहीं गया।

किसे पीकेसीई चाहिए?

क्लाइंट प्रकार	पीकेसीई
नेटिव / मोबाइल	अनिवार्य
बिना सीक्रेट वाला ब्राउज़र एसपीए	अनिवार्य
कॉन्फ़िडेंशियल सर्वर / बीएफएफ	ज़ोरदार सिफ़ारिश (ओऑथ २.१ इसे स्टैंडर्ड मानता है)

प्रोडक्शन में plain विधि मत इस्तेमाल करें। S256 लें।

पीकेसीई स्केच (ब्राउज़र या नोड)

function base64UrlEncode(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)))
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '');
}

async function createPkcePair() {
  const verifierBytes = crypto.getRandomValues(new Uint8Array(32));
  const codeVerifier = base64UrlEncode(verifierBytes);
  const digest = await crypto.subtle.digest(
    'SHA-256',
    new TextEncoder().encode(codeVerifier)
  );
  const codeChallenge = base64UrlEncode(digest);
  return { codeVerifier, codeChallenge };
}

codeVerifier सिर्फ़ लॉगिन प्रयास के दौरान रखें (सेशनस्टोरेज, मेमोरी, या बीएफएफ की सर्वर सेशन)। कभी लॉग न करें।

टोकन: हर एक किस काम का

टोकन	ऑडियंस	सामान्य जीवन	उद्देश्य
ऑथराइज़ेशन कोड	सिर्फ़ टोकन एंडपॉइंट	सेकंड से कुछ मिनट, एक बार उपयोग	ब्राउज़र रीडायरेक्ट से टोकन रिस्पॉन्स तक पुल
ऐक्सेस टोकन	रिसोर्स सर्वर	मिनट (५-६० आम)	एपीआई कॉल पर बेयरर क्रेडेंशियल
रिफ़्रेश टोकन	ऑथराइज़ेशन सर्वर का टोकन एंडपॉइंट	घंटे से दिन/महीने	बिना यूज़र इंटरैक्शन नए ऐक्सेस टोकन
आईडी टोकन (ओआईडीसी)	क्लाइंट	छोटा, ऐक्सेस जैसा या कम	क्लाइंट को पहचान साबित करना; एपीआई कुंजी नहीं

ऐक्सेस टोकन

आमतौर पर जेडब्ल्यूटी या ओपेक रेफ़रेंस टोकन।

जेडब्ल्यूटी: रिसोर्स सर्वर हस्ताक्षर और क्लेम ऑफ़लाइन जाँच सकता है (इशूअर, ऑडियंस, एक्सपायरी, स्कोप)। बड़ा; बिना छोटे टीटीएल या डेनिलिस्ट के तुरंत रिवोक मुश्किल।
ओपेक: रिसोर्स सर्वर ऑथराइज़ेशन सर्वर पर इंट्रोस्पेक्ट करता है (या कैश)। वायर पर छोटा, केंद्रीय रिवोकेशन, अतिरिक्त हॉप या कैश जटिलता।

ऐक्सेस टोकन Authorization: Bearer हेडर में भेजें। क्वेरी स्ट्रिंग में मत डालें। उन यूआरएल में मत डालें जो एनालिटिक्स, सीडीएन लॉग या ब्राउज़र इतिहास में जाएँ।

रिफ़्रेश टोकन

रिफ़्रेश टोकन ऐक्सेस से ज़्यादा संवेदनशील होते हैं क्योंकि वे लंबे चलते हैं और नए ऐक्सेस बनाते हैं।

दर्द रोकने वाले नियम:

१. उन्हें वहीं स्टोर करें जहाँ सुरक्षा संभव हो (बीएफएफ पर एचटीटीपीओनली सुरक्षित कुकी, मोबाइल पर ओएस कीचेन, सर्वर-साइड एन्क्रिप्टेड सेशन)। पब्लिक एसपीए पर localStorage जितना हो टालें। २. रिफ़्रेश टोकन रोटेशन चुनें: हर रिफ़्रेश नया रिफ़्रेश लौटाए और पुराना अमान्य करे। पुराने रिफ़्रेश का दोबारा उपयोग चोरी का संकेत; परिवार रिवोक करें। ३. रिफ़्रेश को क्लाइंट आईडी से बाँधें (और जहाँ उपलब्ध हो, सेंडर-कंस्ट्रेन्ड तंत्र)। ४. रिफ़्रेश का स्कोप कम रखें: ऑफ़लाइन ऐक्सेस स्पष्ट होना चाहिए (offline_access या प्रोवाइडर फ़्लैग), हर लॉगिन का डिफ़ॉल्ट नहीं।

आईडी टोकन

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

रीडायरेक्ट यूआरआई: वह फ़ुटगन जो चुकाता रहता है

ऑथराइज़ेशन सर्वर redirect_uri का सटीक मिलान करते हैं (स्कीम, होस्ट, पाथ, अक्सर पोर्ट और ट्रेलिंग स्लैश)। आंशिक मिलान और वाइल्डकार्ड वहीं हैं जहाँ अकाउंट टेकओवर शुरू होते हैं।

सख्त नियम:

१. पूरी रीडायरेक्ट यूआरआई रजिस्टर करें। प्रोडक्शन में खुले वाइल्डकार्ड नहीं। २. सिर्फ़ https प्राथमिकता दें। नेटिव ऐप के लिए क्लेम्ड एचटीटीपीएस ऐप लिंक्स या प्लेटफ़ॉर्म-अनुशंसित लूपबैक / प्राइवेट-यूज़ यूआरआई स्कीम सावधानी से। ३. केवल क्लाइंट क्वेरी से आए redirect_uri बिना सर्वर अलाउलिस्ट के स्वीकार न करें (एएस को रजिस्ट्रेशन लागू करना है)। ४. रीडायरेक्ट यूआरआई पर सीक्रेट न जोड़ें।

लॉगिन के बाद अपने ही डोमेन पर ओपन रीडायरेक्ट भी ख़तरनाक है: हमलावर यूज़र को ओऑथ से गुज़ारता है, आपके कॉलबैक पर लाता है, फिर फ़िशिंग पेज पर भेजता है जो "सेशन जारी" जैसा दिखता है।

`state` और सीएसआरएफ

state पैरामीटर एक ओपेक मान है जो क्लाइंट /authorize से पहले बनाता है और वापसी पर जाँचता है। यह कॉलबैक को उस ब्राउज़र सेशन से बाँधता है जिसने लॉगिन शुरू किया।

बिना state (या ओआईडीसी nonce कहानी और सेशन बाइंडिंग जैसे समकक्ष) के लॉगिन सीएसआरएफ संभव है: हमलावर फ़्लो शुरू करता है, पीड़ित को पूरा करवाता है, और हमलावर का अकाउंट पीड़ित के सेशन से जोड़ देता है (या डिज़ाइन के अनुसार उल्टा)।

state सीएसपीआरएनजी से बनाएँ, सर्वर-साइड या यूज़र एजेंट से बंधी कुकी/सेशन में रखें, कॉन्स्टेंट-टाइम समानता से मिलाएँ, फिर मिटाएँ। एक बार उपयोग।

इम्प्लिसिट फ़्लो और पासवर्ड ग्रांट: बंद करें

इम्प्लिसिट फ़्लो (response_type=token) ऐक्सेस टोकन यूआरएल फ्रैगमेंट में लौटाता था। पुराने ब्राउज़र बिना सीक्रेट टोकन एंडपॉइंट से बात नहीं कर पाते थे, इसलिए यह था। वह दुनिया खत्म। ऑथराइज़ेशन कोड + पीकेसीई लें।

रिसोर्स ओनर पासवर्ड क्रेडेंशियल्स ग्रांट (grant_type=password) यूज़र का पासवर्ड आपकी ऐप में इकट्ठा कर टोकन एंडपॉइंट पर भेजता है। थर्ड-पार्टी क्लाइंट के लिए ओऑथ का मतलब तोड़ता है और ओऑथ २.१ से हटाया गया। नए डिज़ाइन से बाहर। बहुत नियंत्रित फ़र्स्ट-पार्टी मामलों में ऑथराइज़ेशन कोड या डिवाइस फ़्लो, या अपने आईडीपी पर सही सेशन लॉगिन चुनें।

डिवाइस ऑथराइज़ेशन ग्रांट सीएलआई और सीमित इनपुट वाले डिवाइस (टीवी, आईओटी) के लिए सही औज़ार है: कोड दिखाएँ, यूज़र फ़ोन पर मंज़ूरी दे, डिवाइस टोकन के लिए पोल करे।

आम बग (जो शिप हो जाते हैं)

१. एसपीए और मोबाइल पर पीकेसीई छोड़ना

लक्षण: "क्रोम में चलता है।" इंसिडेंट: कस्टम यूआरएल स्कीम इंटरसेप्शन या लीक रीडायरेक्ट लॉग हमलावर के लिए टोकन बनाते हैं। सुधार: पब्लिक क्लाइंट पर हमेशा पीकेसीई; बीएफएफ बेहतर ताकि ब्राउज़र रिफ़्रेश न रखे।

२. `state` जाँच नहीं

लक्षण: कॉलबैक /callback पर आए किसी भी code पर भरोसा। सुधार: state को सेशन से बाँधें; मिसमैच अस्वीकार करें।

३. `localStorage` में ऐक्सेस टोकन

एक्सएसएस टोकन जीवन भर (और रिफ़्रेश वहाँ हो तो और लंबा) अकाउंट टेकओवर बन जाता है। बीएफएफ से एचटीटीपीओनली कुकी, या सावधानी से रिफ़्रेश डिज़ाइन के साथ सिर्फ़ मेमोरी में छोटा ऐक्सेस चुनें। स्टोरेज एपीआई ज़रूरी हों तो मान लें एक्सएसएस = सेशन चोरी; सीएसपी, सैनिटाइज़ेशन और छोटे टीटीएल में निवेश करें।

४. क्वेरी स्ट्रिंग में टोकन

GET /api/items?access_token=eyJhbGciOi...

लॉग, प्रॉक्सी, ब्राउज़र इतिहास और Referer उन्हें इकट्ठा करते हैं। ऑथराइज़ेशन हेडर इस्तेमाल करें।

५. गलत या ढीली रीडायरेक्ट यूआरआई रजिस्ट्रेशन

https://app.example.com/* या बिना सख्त मिलान के redirect_uri ओवरराइड स्वीकार करना कोड लूटने देता है। हर एनवायरनमेंट के लिए सटीक यूआरआई रजिस्टर करें।

६. आईडी टोकन को एपीआई क्रेडेंशियल मानना

जो एपीआई सिर्फ़ देखते हैं "क्या यह हमारे आईडीपी से साइन जेडब्ल्यूटी है?" और उस एपीआई के ऑडियंस की जाँच नहीं करतीं, वे दूसरे क्लाइंट के लिए बने टोकन स्वीकार कर लेती हैं। iss, aud, exp, हस्ताक्षर (और nbf हो तो) मान्य करें। ऐक्सेस टोकन पर ज़रूरी स्कोप या क्लेम लागू करें।

७. अनंत जीवन वाले ऐक्सेस टोकन

बिना exp, या "ट्रैफ़िक कम करने" के लिए ३०-दिन ऐक्सेस। छोटा ऐक्सेस टीटीएल + रिफ़्रेश। रिवोकेशन को अर्थ दें।

८. बिना रोटेशन या रीयूज़ डिटेक्शन का रिफ़्रेश

चुराया रिफ़्रेश मैन्युअल रिवोक तक चलता है। रोटेशन + रीयूज़ डिटेक्शन खिड़की सीमित करता है और चोरी दिखाता है।

९. एनवायरनमेंट मिलाना

डेव client_id प्रोड ऑथराइज़ यूआरएल पर, या प्रोड रीडायरेक्ट सिर्फ़ स्टेजिंग पर रजिस्टर्ड। लक्षण बेतरतीब invalid_grant और redirect_uri_mismatch लगते हैं। हर एनवायरनमेंट अलग क्लाइंट।

१०. टोकन रिस्पॉन्स लॉग करना

रिक्वेस्ट/रिस्पॉन्स बॉडी डंप करने वाले ऐक्सेस लॉग बेयरर टोकन छापते हैं। Authorization, code, code_verifier और टोकन एंडपॉइंट बॉडी रेडैक्ट करें।

११. घड़ी का विचलन

सर्वर समय पर सहमत न हों तो जेडब्ल्यूटी वैलिडेशन बीच-बीच में फेल। छोटी समय-विचलन खिड़की (लगभग एक मिनट) दें और एनटीपी चलाएँ। exp जाँच बंद करके "ठीक" न करें।

१२. सहमति पर स्कोप बढ़ाना

सैंपल ऐप ने माँगा इसलिए admin या पूरा मेलबॉक्स। यूज़र सहमति रोकता है, सिक्योरिटी रिव्यू फेल, ब्रीच असर बढ़ता है। स्क्रीन को जितना चाहिए उतना स्कोप; फ़ीचर ज़्यादा माँगे तो स्टेप-अप।

१३. सीओआरएस को सुरक्षा समझना

सीओआरएस जावास्क्रिप्ट में बैठे टोकन की रक्षा नहीं करता। यह सिर्फ़ सीमित करता है कौन सा ओरिजिन ब्राउज़र में रिस्पॉन्स पढ़ सकता है। सर्वर-साइड कॉलर सीओआरएस पूरी तरह नज़रअंदाज़ करते हैं।

१४. घर का "ओऑथ-जैसा" क्रिप्टो

लंबे साझा सीक्रेट वाले होमग्रोन एन्क्रिप्टेड ब्लॉब, बिना स्टैंडर्ड रिवोक, बिना ऑडियंस। असली ऑथराइज़ेशन सर्वर या उसके ख़िलाफ़ मेंटेंड लाइब्रेरी लें।

बीएफएफ पैटर्न (संक्षिप्त)

एसपीए के लिए एक आम मज़बूत आकार:

१. ब्राउज़र सिर्फ़ आपके बैकएंड से बात करे (सेम-साइट कुकी)। २. बैकएंड ओऑथ क्लाइंट हो (कॉन्फ़िडेंशियल), कोड + पीकेसीई चलाए, रिफ़्रेश टोकन रखे। ३. बैकएंड ब्राउज़र को अपनी सेशन कुकी दे। ४. ब्राउज़र आईडीपी के ऐक्सेस/रिफ़्रेश कभी न देखे।

थोड़ी बैकएंड जटिलता के बदले एक्सएसएस का असर बहुत छोटा और टोकन स्टोरेज साफ़। कई एंटरप्राइज़ आईडीपी ब्राउज़र ऐप के लिए इसे साफ़ दस्तावेज़ करते हैं।

रिसोर्स सर्वर चेकलिस्ट

जब आपकी एपीआई बेयरर टोकन स्वीकार करे:

वर्तमान जेडब्ल्यूकेएस से हस्ताक्षर मान्य करें (की कैश, रोटेशन संभालें)
iss, aud, exp जाँचें (nbf हो तो वह भी)
रूट के हिसाब से स्कोप या महीन क्लेम लागू करें
गलत टोकन टाइप/उपयोग अस्वीकार करें (अगर आईडीपी फ़र्क रखे)
एपीआई-प्रतिबंधित ऑडियंस वाले ऐक्सेस टोकन प्राथमिकता
ऑडिट के लिए sub / क्लाइंट आईडी लॉग करें, कच्चा टोकन कभी नहीं
रिवोक्ड टोकन का व्यवहार तय करें (छोटा टीटीएल, इंट्रोस्पेक्शन, या डेनिलिस्ट)

क्लाइंट चेकलिस्ट

ऑथराइज़ेशन कोड + पीकेसीई (S256), इम्प्लिसिट नहीं
क्रिप्टोग्राफ़िक state, एक बार मान्य, फिर साफ़
हर एनवायरनमेंट पर सटीक रीडायरेक्ट यूआरआई
टोकन यूआरएल या लॉग में नहीं
रिफ़्रेश रोटेशन और स्टोरेज थ्रेट मॉडल लिखा हुआ
डेव / स्टेज / प्रोड के अलग क्लाइंट
न्यूनतम स्कोप; हर स्कोप क्यों है दस्तावेज़ में
लॉगआउट / रिवोक पाथ परीक्षित (आईडीपी सेशन + लोकल सेशन)
invalid_grant, सहमति इनकार, और घड़ी-विचलन के लिए एरर हैंडलिंग

ओऑथ २.१ सोच से मेल

ओऑथ २.१ बेस्ट प्रैक्टिस का समेकन है, पूरी तरह नया प्रोटोकॉल नहीं। इम्प्लीमेंटर के लिए दिशा:

ऑथराइज़ेशन कोड इंटरैक्टिव मुख्य औज़ार है।
कोड फ़्लो वाले सभी क्लाइंट पर पीकेसीई।
इम्प्लिसिट और पासवर्ड ग्रांट हटाए।
रीडायरेक्ट यूआरआई सटीक मिलान।
रिफ़्रेश रोटेशन प्रोत्साहित; बेयरर टोकन संवेदनशील माने जाएँ।

अगर आपकी आंतरिक विकी अभी कहती है "एसपीए को इम्प्लिसिट चाहिए," प्रोड छूने से पहले विकी अपडेट करें।

समापन

ऑथराइज़ेशन कोड + पीकेसीई शिप करें, रीडायरेक्ट यूआरआई और state को सुरक्षा नियंत्रण मानें, ऐक्सेस टोकन छोटे और रिफ़्रेश टोकन उबाऊ ढंग से सुरक्षित रखें, और रिसोर्स सर्वर पर टोकन इशूअर, ऑडियंस, एक्सपायरी और स्कोप से मान्य करें। ज़्यादातर "ओऑथ मुश्किल है" इंसिडेंट विदेशी क्रिप्टो विफलता नहीं। छोड़ी गई जाँचें, गलत जगह टोकन, और दूसरे क्लाइंट प्रकार का सैंपल कोड हैं।

कल पीआर रिव्यू हो तो यहीं से शुरू करें: पीकेसीई मौजूद, state जाँचा, रीडायरेक्ट अलाउलिस्ट सटीक, टोकन स्टोरेज लिखा, क्वेरी स्ट्रिंग में कोई बेयरर नहीं। यह छोटी सूची असली बग का बड़ा हिस्सा पकड़ती है।