OAuth 2.0 और OIDC: प्रमाणीकरण, प्राधिकरण और टोकन सत्यापन

OAuth 2.0 एक प्राधिकरण ढाँचा है, जो एप्लिकेशन को सीमित एक्सेस देता है। OpenID Connect (OIDC) इसके ऊपर उपयोगकर्ता के प्रमाणीकरण का परिणाम क्लाइंट तक पहुँचाने की व्यवस्था जोड़ता है।

इस लेख में प्रमाणीकरण और प्राधिकरण, टोकन के उद्देश्य, PKCE के साथ प्राधिकरण कोड और ID टोकन सत्यापन को अलग-अलग समझाया गया है। कोड केवल कुछ चरणों के उदाहरण हैं; वे पूर्ण लॉगिन कार्यान्वयन नहीं हैं। वास्तविक सेवा में अपनी आवश्यकताओं के अनुरूप OIDC लाइब्रेरी और प्रदाता का कॉन्फ़िगरेशन इस्तेमाल करें।

1. प्रमाणीकरण और प्राधिकरण

प्रमाणीकरण (Authentication / AuthN)

प्रमाणीकरण प्रस्तुत प्रमाण के आधार पर उपयोगकर्ता या सिस्टम की पहचान की जाँच करता है। इसकी तुलना कंपनी के स्वागत कक्ष में कर्मचारी का पहचान पत्र जाँचने से की जा सकती है।

प्राधिकरण (Authorization / AuthZ)

प्राधिकरण तय करता है कि कोई व्यक्ति या सिस्टम कौन-से कार्य कर सकता है और किन संसाधनों तक पहुँच सकता है। किसी के कर्मचारी होने की पुष्टि का अर्थ यह नहीं कि वह हर सर्वर कक्ष में जा सकता है।

पहलू	प्रमाणीकरण	प्राधिकरण
प्रश्न	यह कौन है?	क्या करने की अनुमति है?
संक्षिप्त नाम	AuthN	AuthZ
यहाँ वर्णित व्यवस्था	OIDC प्रमाणीकरण का परिणाम बताता है	OAuth 2.0 सीमित एक्सेस देता है
टोकन का उदाहरण	OIDC का ID टोकन	OAuth 2.0 का एक्सेस टोकन

हर प्रमाणीकरण विधि ID टोकन जारी नहीं करती। OAuth 2.0 भी एप्लिकेशन के भीतर का पूरा एक्सेस नियंत्रण परिभाषित नहीं करता। टोकन मिलने के बाद भी API को विशेष संसाधन और कार्य के लिए आवश्यक अनुमतियाँ जाँचनी होती हैं।

OAuth 2.0 अपने आप यह मानकीकृत नहीं करता कि क्लाइंट उपयोगकर्ता के प्रमाणीकरण का परिणाम कैसे जाँचे। केवल एक्सेस टोकन मिलने से लॉगिन सफल नहीं मानना चाहिए। OIDC जैसे प्रोटोकॉल का उपयोग करें, जो उस परिणाम का सत्यापन करने देता है।

2. OAuth 2.0 की भूमिकाएँ और ग्रांट प्रकार

2.1 सीमित एक्सेस

OAuth 2.0 में क्लाइंट संसाधन स्वामी की ओर से या अपनी ओर से एक्सेस टोकन प्राप्त करता है। उपयोगकर्ता का पासवर्ड क्लाइंट को दिए बिना एक्सेस सौंपना प्राधिकरण कोड प्रवाह की एक महत्वपूर्ण विशेषता है।

2.2 चार भूमिकाएँ

संसाधन स्वामी (Resource Owner): वह पक्ष जो संरक्षित संसाधन तक एक्सेस की अनुमति दे सकता है। उसका मनुष्य होना आवश्यक नहीं है।
क्लाइंट (Client): संरक्षित संसाधनों का उपयोग करने वाला एप्लिकेशन।
प्राधिकरण सर्वर (Authorization Server): लागू प्रवाह के अनुसार प्राधिकरण, क्लाइंट प्रमाणीकरण और अन्य शर्तें जाँचकर टोकन जारी करने वाला सर्वर।
संसाधन सर्वर (Resource Server): टोकन और अनुमतियाँ जाँचकर संरक्षित संसाधन उपलब्ध कराने वाला सर्वर।

2.3 मुख्य ग्रांट प्रकार

प्राधिकरण कोड ग्रांट (Authorization Code Grant)

प्राधिकरण प्रतिक्रिया में कम समय के लिए वैध कोड लौटता है, जिसे टोकन एंडपॉइंट पर एक्सेस टोकन से बदला जाता है। सर्वर पर क्रेडेंशियल सुरक्षित रख सकने वाले गोपनीय क्लाइंट (confidential clients) और SPA या नेटिव ऐप जैसे सार्वजनिक क्लाइंट (public clients), दोनों इसे PKCE के साथ इस्तेमाल कर सकते हैं। वितरित ऐप या ब्राउज़र कोड में क्लाइंट सीक्रेट डालने से वह गुप्त नहीं रहता।

इम्प्लिसिट ग्रांट (Implicit Grant)

इस विधि में प्राधिकरण प्रतिक्रिया सीधे एक्सेस टोकन लौटाती है। इसमें टोकन लीक होने, इंजेक्शन और दोबारा इस्तेमाल के जोखिम हैं। RFC 9700 के अनुसार क्लाइंट को इसका उपयोग नहीं करना चाहिए (SHOULD NOT), जब तक बताए गए जोखिम कम करने की शर्तें पूरी न हों। नए कॉन्फ़िगरेशन में प्राधिकरण कोड और PKCE चुनें। इस सिफारिश को OIDC की सभी प्रतिक्रिया विधियों पर एक जैसा प्रतिबंध न समझें।

संसाधन स्वामी पासवर्ड क्रेडेंशियल ग्रांट (ROPC)

इस विधि में क्लाइंट उपयोगकर्ता का पासवर्ड सीधे लेता है। RFC 6749 इसका वर्णन करता है, लेकिन अद्यतन सुरक्षा दिशानिर्देश RFC 9700 के अनुसार इसका उपयोग करना निषिद्ध है (MUST NOT)। पुराने सिस्टम का माइग्रेशन अनुशंसित अपवाद के रूप में प्रस्तुत नहीं करना चाहिए।

क्लाइंट क्रेडेंशियल ग्रांट (Client Credentials Grant)

गोपनीय क्लाइंट अपना प्रमाणीकरण करके टोकन प्राप्त करता है। वह अपने नियंत्रण वाले संसाधनों या प्राधिकरण सर्वर के साथ पहले से हुए समझौते के अनुसार किसी अन्य संसाधन स्वामी के संसाधनों तक पहुँच सकता है। यह सामान्यतः उपयोगकर्ता की सहभागिता के बिना सिस्टमों के बीच संचार के लिए है; क्लाइंट अनिवार्य रूप से संसाधन स्वामी नहीं बन जाता।

2.4 प्राधिकरण कोड और PKCE

PKCE (Proof Key for Code Exchange) प्राधिकरण अनुरोध शुरू करने वाले क्लाइंट को कोड के बदले टोकन लेने वाले क्लाइंट से जोड़ता है। इससे कोड इंटरसेप्शन और इंजेक्शन के विरुद्ध सुरक्षा मिलती है। सार्वजनिक क्लाइंट के लिए PKCE अनिवार्य है और गोपनीय क्लाइंट के लिए भी अनुशंसित है। यह गोपनीय क्लाइंट के लिए आवश्यक क्लाइंट प्रमाणीकरण का विकल्प नहीं है।

हर प्राधिकरण प्रयास के लिए क्लाइंट नया गुप्त code_verifier बनाता है। RFC 7636 में अंग्रेज़ी अक्षरों, अंकों और -._~ से बने 43–128 वर्ण निर्धारित हैं तथा कम से कम 256 बिट एंट्रॉपी की सिफारिश है। क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक जनरेटर से प्राप्त 32 बाइट को बिना पैडिंग वाले Base64url में एनकोड करने पर 43 वर्ण मिलते हैं।

S256 के लिए चैलेंज की गणना इस प्रकार है। Base64url के अंत में = पैडिंग नहीं रखी जाती।

\[ \text{code\_challenge}=\operatorname{BASE64URL}\!\left(\operatorname{SHA256}\!\left(\operatorname{ASCII}(\text{code\_verifier})\right)\right) \]

प्राधिकरण अनुरोध में code_challenge और code_challenge_method=S256 भेजे जाते हैं। टोकन अनुरोध में उसी प्रयास के लिए रखा गया code_verifier भेजते हैं। सर्वर कोड के साथ दर्ज विधि और चैलेंज से इसकी जाँच करता है। S256 विफल होने पर plain पर वापस नहीं जाना चाहिए।

प्रवाह का संक्षिप्त चित्र

  sequenceDiagram
    autonumber
    participant U as "उपयोगकर्ता / ब्राउज़र"
    participant C as "क्लाइंट"
    participant AS as "प्राधिकरण सर्वर / OIDC का OP"
    participant RS as "संसाधन सर्वर"
    Note over C: "हर प्रयास के लिए verifier और state रखें; OIDC में nonce भी रखें"
    C->>U: "प्राधिकरण एंडपॉइंट पर रीडायरेक्ट करें"
    U->>AS: "अनुरोध: challenge और S256; OIDC में openid और nonce भी"
    AS-->>U: "ज़रूरत के अनुसार प्रमाणीकरण और सहमति माँगें"
    U->>AS: "प्रमाणीकरण और प्राधिकरण की प्रक्रिया पूरी करें"
    AS-->>U: "पंजीकृत redirect_uri पर code और state के साथ रीडायरेक्ट करें"
    U->>C: "कॉलबैक: code और state"
    Note over C: "प्रयास, state और अपेक्षित जारीकर्ता जाँचें"
    C->>AS: "code, verifier और आवश्यक क्लाइंट प्रमाणीकरण के साथ विनिमय करें"
    Note over AS: "कोड, बाइंडिंग और PKCE सत्यापित करें"
    AS-->>C: "एक्सेस टोकन लौटाएँ; OIDC में ID टोकन भी"
    Note over C: "OIDC में ID टोकन और nonce सत्यापित करें"
    C->>RS: "एक्सेस टोकन के साथ API कॉल करें"
    RS-->>C: "टोकन और अनुमतियाँ जाँचकर संसाधन लौटाएँ"

यह सफल प्रवाह का संक्षिप्त चित्र है। संचार को TLS से सुरक्षित रखें। कार्यान्वयन में रीडायरेक्ट लक्ष्य की जाँच, कोड का एक बार उपयोग, त्रुटि प्रतिक्रियाएँ, प्रयास की समय सीमा और कई प्राधिकरण सर्वर होने पर mix-up हमलों से बचाव भी संभालना होता है।

PKCE पैरामीटर बनाना (JavaScript / Web Crypto API)

ये ब्राउज़र फ़ंक्शन HTTPS जैसे सुरक्षित संदर्भ में चलते हैं। generatePkce() केवल पैरामीटर लौटाता है; यह प्राधिकरण अनुरोध नहीं भेजता और प्रयास की जानकारी सहेजता भी नहीं है। verifier को लॉग या URL में न दिखाएँ। उसे अनुरोध शुरू करने वाले ब्राउज़र के प्रयास से बाँधकर रखें और विनिमय पूरा होने या समय सीमा बीतने पर हटा दें।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
function base64url(bytes) {
    return btoa(String.fromCharCode(...bytes))
        .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
}

function generateCodeVerifier() {
    const bytes = new Uint8Array(32);
    crypto.getRandomValues(bytes);
    return base64url(bytes);
}

async function generateCodeChallenge(codeVerifier) {
    if (typeof codeVerifier !== 'string' ||
        codeVerifier.length < 43 || codeVerifier.length > 128 ||
        /[^A-Za-z0-9._~-]/.test(codeVerifier)) {
        throw new TypeError('Invalid PKCE verifier');
    }
    const data = new TextEncoder().encode(codeVerifier);
    const digest = await crypto.subtle.digest('SHA-256', data);
    return base64url(new Uint8Array(digest));
}

async function generatePkce() {
    const code_verifier = generateCodeVerifier();
    return {
        code_verifier,
        code_challenge: await generateCodeChallenge(code_verifier),
        code_challenge_method: 'S256'
    };
}

यह कोड यादृच्छिक 32 बाइट के सभी बिट एनकोड करता है। पुराने उदाहरण में 28 यादृच्छिक 32-बिट पूर्णांकों के केवल अंतिम दो हेक्साडेसिमल अंक जोड़े जाते थे। 896 बिट लेने के बावजूद केवल 224 बिट बचते थे। यह कटौती ठीक कर दी गई है।

3. OIDC और ID टोकन

3.1 OAuth के ऊपर प्रमाणीकरण परत

OIDC में क्लाइंट (Relying Party) openid स्कोप के साथ प्रमाणीकरण माँगता है और OpenID Provider (OP) ID टोकन में परिणाम लौटाता है। उपयोगकर्ता को हर बार पासवर्ड डालना आवश्यक नहीं है; OP मौजूदा सत्र या किसी अन्य प्रमाणीकरण विधि का उपयोग कर सकता है।

3.2 टोकन के उद्देश्य अलग रखें

एक्सेस टोकन: संसाधन सर्वर तक पहुँचने का क्रेडेंशियल। इसका प्रारूप JWT या अपारदर्शी स्ट्रिंग हो सकता है; OAuth 2.0 एक ही प्रारूप अनिवार्य नहीं करता। क्लाइंट को आंतरिक संरचना का अनुमान लगाने के बजाय API के निर्देशों का पालन करना चाहिए।
ID टोकन: क्लाइंट के लिए प्रमाणीकरण परिणाम दर्शाने वाला JWT। उपयोग से पहले हस्ताक्षर, क्लेम और प्रमाणीकरण अनुरोध से उसका संबंध सत्यापित करें। केवल डिकोड करना पर्याप्त नहीं है। इसे API के एक्सेस टोकन की जगह भी नहीं भेजना चाहिए।

3.3 JWT की संरचना और हस्ताक्षर

इस खंड में बिना एन्क्रिप्शन वाले हस्ताक्षरित JWT का JWS Compact Serialization समझाया गया है। इसमें बिंदु से अलग किए गए तीन भाग होते हैं। JWT को JWE के रूप में एन्क्रिप्ट या नेस्ट भी किया जा सकता है; उसके हमेशा तीन ही भाग नहीं होते।

Header (हेडर): हस्ताक्षर एल्गोरिदम alg और कुंजी पहचानकर्ता kid जैसे फ़ील्ड।
Payload (पेलोड): जारीकर्ता, प्राप्तकर्ता, समाप्ति समय, विषय और अन्य जानकारी के क्लेम।
Signature (हस्ताक्षर): निर्धारित एल्गोरिदम से बना हस्ताक्षर या MAC। यहाँ RS256 में RSA डिजिटल हस्ताक्षर का उपयोग होता है।

हेडर और पेलोड केवल Base64url में एनकोड होते हैं। हस्ताक्षर उनकी सामग्री नहीं छिपाता। एन्क्रिप्शन, हैश और हस्ताक्षर का अंतर भी देखें।

ID टोकन के मुख्य अनिवार्य क्लेम

iss: OP का जारीकर्ता पहचानकर्ता। इसे अपेक्षित जारीकर्ता से बिल्कुल मेल खाना चाहिए।
sub: उस जारीकर्ता के दायरे में अद्वितीय उपयोगकर्ता पहचानकर्ता, जिसे किसी दूसरे उपयोगकर्ता को दोबारा नहीं दिया जाता। कई OP होने पर उपयोगकर्ता की पहचान के लिए इसे iss के साथ मिलाएँ।
aud: अपेक्षित प्राप्तकर्ता। जाँचें कि इसमें क्लाइंट का client_id शामिल है और ऐसे अतिरिक्त प्राप्तकर्ता स्वीकार न करें जिन पर क्लाइंट भरोसा नहीं करता।
exp: समाप्ति का समय। वर्तमान समय इससे पहले होना चाहिए।
iat: जारी करने का समय। टोकन कितना पुराना स्वीकार्य है और अन्य सीमाएँ क्लाइंट की नीति तय करती है।

यदि प्रमाणीकरण अनुरोध में nonce भेजा गया था, तो उस क्लेम की मौजूदगी अनिवार्य करें और उसका मान जाँचें। अतिरिक्त क्लेम या max_age माँगने पर उनके अनुरूप सत्यापन भी आवश्यक है।

RS256 के हस्ताक्षर का इनपुट

मान लें कि H UTF-8 में संरक्षित हेडर है, P UTF-8 में पेलोड है और B64u बिना पैडिंग की Base64url एनकोडिंग है। हस्ताक्षर के लिए निम्न बाइट क्रम लिया जाता है; || जोड़ने का संकेत है।

\[ M=\operatorname{ASCII}\!\left(\operatorname{B64u}(H)\,||\,\texttt{.}\,||\,\operatorname{B64u}(P)\right),\qquad S=\operatorname{Sign}_{\mathrm{RS256}}(sk,M) \]

RS256 में SHA-256 के साथ RSASSA-PKCS1-v1_5 का उपयोग होता है। हैश की गणना इस हस्ताक्षर एल्गोरिदम का हिस्सा है; सूत्र बाहर से एक और हैश नहीं जोड़ता। टोकन का तीसरा भाग B64u(S) है। भरोसेमंद OP की सार्वजनिक कुंजी और निर्धारित एल्गोरिदम से हस्ताक्षर जाँचें। हस्ताक्षर सत्यापन को सामान्यतः “सार्वजनिक कुंजी से डिक्रिप्ट करना” नहीं कहना चाहिए।

असत्यापित टोकन को अनुमत एल्गोरिदम या कुंजी का स्रोत तय न करने दें। सत्यापित OP कॉन्फ़िगरेशन या Discovery प्रक्रिया से मिला भरोसेमंद JWKS इस्तेमाल करें और कुंजी रोटेशन तथा कैश संभालें। kid उसी भरोसेमंद कुंजी समूह में चुनाव के लिए है; टोकन में दिए किसी मनमाने URL से कुंजी न लें।

Python में सत्यापन का आंशिक उदाहरण

निम्न PyJWT फ़ंक्शन सीमित कॉन्फ़िगरेशन के लिए है: RS256, बिना एन्क्रिप्शन, स्ट्रिंग के रूप में एक प्राप्तकर्ता और अनुरोध में पहले भेजा गया nonce। कॉल करने वाला कोड भरोसेमंद OP के JWKS से मिली सार्वजनिक कुंजी signing_key के रूप में देता है। अनिवार्य क्लेम की मौजूदगी और उनके मान, दोनों सत्यापित होने चाहिए। यदि azp मौजूद है, तो इस कॉन्फ़िगरेशन में उसका मान client_id से मेल खाना चाहिए।

यह फ़ंक्शन पूरा लॉगिन नहीं करता। कॉल करने वाले कोड को कॉलबैक और आरंभिक प्रयास का संबंध, state, कोड विनिमय, अपेक्षित जारीकर्ता और nonce का एक बार उपयोग सत्यापित तथा प्रबंधित करना होता है। कई प्राप्तकर्ता, एन्क्रिप्शन, अतिरिक्त प्रमाणीकरण आवश्यकताएँ, max_age और acr इस उदाहरण के दायरे से बाहर हैं।

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
import hmac
import math
import jwt


def verify_id_token(id_token, signing_key, *, issuer, client_id, expected_nonce):
    if not isinstance(expected_nonce, str) or not expected_nonce:
        raise ValueError('A nonce from the stored transaction is required')
    claims = jwt.decode(
        id_token,
        signing_key,
        algorithms=['RS256'],
        audience=client_id,
        issuer=issuer,
        options={
            'require': ['iss', 'sub', 'aud', 'exp', 'iat', 'nonce'],
            'strict_aud': True,
        },
    )
    for name in ('exp', 'iat'):
        value = claims[name]
        if (isinstance(value, bool) or not isinstance(value, (int, float))
                or (isinstance(value, float) and not math.isfinite(value))):
            raise jwt.InvalidTokenError('Invalid NumericDate')
    subject = claims['sub']
    if (not isinstance(subject, str) or not subject or not subject.isascii()
            or len(subject) > 255):
        raise jwt.InvalidTokenError('Invalid subject')
    nonce = claims['nonce']
    if (not isinstance(nonce, str) or not hmac.compare_digest(
            nonce.encode('utf-8'), expected_nonce.encode('utf-8'))):
        raise jwt.InvalidTokenError('Nonce mismatch')
    if 'azp' in claims and claims['azp'] != client_id:
        raise jwt.InvalidTokenError('Authorized party mismatch')
    return claims

यह फ़ंक्शन ऊपर बताए दायरे में सत्यापित क्लेम लौटाता है। केवल सही हस्ताक्षर के आधार पर “प्रमाणीकरण सफल” न दिखाएँ और असत्यापित नाम या ईमेल पते से खाते न जोड़ें।

4. सुरक्षा संबंधी जाँच

4.1 state, nonce, PKCE और CSRF

state का उपयोग करते समय ऐसा मान चुनें जिसका अनुमान लगाना कठिन हो और उसे अनुरोध शुरू करने वाले ब्राउज़र के प्रयास से सुरक्षित रूप से बाँधें। कॉलबैक पर उसका मान, समय सीमा और पहले उपयोग न होने की स्थिति जाँचकर उसे उपयोग किया हुआ चिह्नित करें। केवल स्ट्रिंग का मेल सभी प्रकार के CSRF को नहीं रोकता।

RFC 9700 सर्वर के PKCE समर्थन की पुष्टि के बाद उसके CSRF संरक्षण पर निर्भर करने की स्थितियों और OIDC nonce के उपयोग का भी वर्णन करता है। इन उपायों में भी हर प्रयास के साथ बाइंडिंग और सही सत्यापन आवश्यक हैं। state, nonce और PKCE की भूमिकाएँ अलग हैं; स्थिर मान या तुलना छोड़ देने से अपेक्षित सुरक्षा नहीं मिलती। कई प्राधिकरण सर्वर होने पर mix-up हमलों से बचाव भी आवश्यक है।

4.2 समय सीमा और रिफ्रेश टोकन

एक्सेस टोकन का छोटा जीवनकाल चोरी हुए टोकन के उपयोग का समय सीमित करने का एक उपाय है। 15 मिनट जैसा मान डिज़ाइन का उदाहरण है, सार्वभौमिक अनिवार्य मान नहीं। हस्ताक्षरित JWT के exp की जाँच में समय सीमा की शर्त यह है:

\[ T_{\mathrm{now}}<T_{\mathrm{exp}},\qquad T_{\mathrm{exp}}=T_{\mathrm{iat}}+D_{\mathrm{lifetime}}\ \text{केवल इस प्रकार निर्धारित होने पर}\ T_{\mathrm{now}}<T_{\mathrm{iat}}+D_{\mathrm{lifetime}} \]

यह केवल समय सीमा की जाँच है; इससे पूरे टोकन की वैधता या एक्सेस अनुमति सिद्ध नहीं होती। एल्गोरिदम, कुंजी, जारीकर्ता, प्राप्तकर्ता तथा लागू होने पर nbf, निरस्तीकरण की स्थिति और प्रमाणीकरण अनुरोध से संबंध भी जाँचें। घड़ियों के अंतर के लिए कोई छूट हो तो उसे स्पष्ट रूप से प्रबंधित करें।

रिफ्रेश टोकन जारी करना वैकल्पिक है। उसके बिना क्लाइंट को नया प्राधिकरण प्रयास करना पड़ सकता है। सार्वजनिक क्लाइंट को जारी रिफ्रेश टोकन के लिए RFC 9700 प्रेषक बंधन (sender constraints) या रोटेशन अनिवार्य करता है। यह टोकन प्रस्तुत करने वाले क्लाइंट के साथ क्रिप्टोग्राफ़िक बाइंडिंग है। रिफ्रेश टोकन रद्द कर देने पर भी, पहले से जारी एक्सेस टोकन तुरंत अमान्य हो जाएँ, यह आवश्यक नहीं है।

4.3 प्रवाह और कार्यान्वयन का चयन

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

निष्कर्ष

OAuth 2.0 एक्सेस टोकन का उपयोग संसाधनों तक पहुँचने के लिए करें। OIDC ID टोकन को क्लाइंट के लिए प्रमाणीकरण परिणाम के रूप में सत्यापित करें। कोड और PKCE का संबंध, हस्ताक्षर, अनिवार्य क्लेम, nonce और कॉलबैक का आरंभिक प्रयास से संबंध, प्रत्येक की जाँच करें।

संदर्भ विनिर्देश

RFC 6749: OAuth 2.0 (भूमिकाएँ, टोकन और क्लाइंट क्रेडेंशियल; अद्यतन सुरक्षा दिशानिर्देश के लिए RFC 9700 देखें)
RFC 7636: PKCE (खंड 4, खंड 7.1 और परिशिष्ट B)
RFC 9700: OAuth 2.0 सुरक्षा दिशानिर्देश (खंड 2.1, 2.2.2 और 2.4)
OpenID Connect Core 1.0 (खंड 2, 3.1.3.7 और 5.7)
RFC 7515: JWS (खंड 3.1 और 5.1)
PyJWT API (अनुमत एल्गोरिदम, अनिवार्य क्लेम और प्राप्तकर्ता का सत्यापन)