ऑरिजिन ट्रायल के साथ, ईमेल पते की पुष्टि करने के प्रोटोकॉल को आज़माना

Rowan Merewood

पब्लिश की गई तारीख: 8 जुलाई, 2026

साइन-अप, साइन-इन, सदस्यता लेने, चेकआउट, खाता वापस पाने या किसी अन्य प्रोसेस के दौरान, ईमेल पता इकट्ठा करना आम बात है. हालांकि, यह पक्का करना ज़रूरी है कि डाला गया ईमेल पता, उस व्यक्ति का हो जिसने उसे डाला है. पुष्टि करने के मौजूदा तरीकों, जैसे कि एक बार इस्तेमाल होने वाले पासवर्ड (ओटीपी) या ईमेल पते की पुष्टि करने वाले लिंक (मैजिक लिंक) के लिए, उपयोगकर्ता को आपकी साइट से बाहर जाना पड़ता है. इस वजह से, उपयोगकर्ता (चाहे वह कोई व्यक्ति हो या एजेंट) अपना सेशन पूरी तरह से छोड़ सकता है और पुष्टि करने की प्रोसेस कभी पूरी नहीं कर सकता. इससे उपयोगकर्ता के लिए जोखिम बढ़ सकता है.

Email Verification API एक ऐसा प्रस्ताव है जो ब्राउज़र को ईमेल की सेवा देने वाली कंपनी से सीधे संपर्क करने की अनुमति देता है. इससे यह पुष्टि की जा सकती है कि ईमेल पता, उपयोगकर्ता का है या नहीं. उपयोगकर्ता, ब्राउज़र के ऑटोमैटिक भरने या अपने-आप पूरा होने वाले सुझाव से कोई ईमेल चुनता है और फ़ॉर्म सबमिट करता है. इसके बाद, साइट, ईमेल की सेवा देने वाली कंपनी से ईमेल पते की पुष्टि करती है. इसके लिए, न तो कोई ईमेल भेजा जाता है और न ही उपयोगकर्ता के फ़्लो में कोई रुकावट आती है.

Email Verification API के उपयोगकर्ता प्रॉम्प्ट का डेमो

ईमेल पता इकट्ठा करना, उपयोगकर्ता के सफ़र में कन्वर्ज़न का एक अहम पॉइंट है. Chrome इस प्रस्ताव पर उन साइटों से सुझाव चाहता है जो ईमेल पतों की पुष्टि करना चाहती हैं. साथ ही, उन ईमेल की सेवा देने वाली कंपनियों से भी सुझाव चाहता है जो पुष्टि कर सकती हैं. इसके अलावा, उन उपयोगकर्ताओं से भी सुझाव चाहता है जो इस प्रोसेस का अनुभव कर रहे हैं. ऑरिजिन ट्रायल के लिए आज ही साइन अप करें. साथ ही, यहां दिए गए निर्देशों के मुताबिक इसे लागू करें. ऑरिजिन ट्रायल को कॉन्फ़िगर करने के बारे में सामान्य जानकारी के लिए, ऑरिजिन ट्रायल के साथ काम करना शुरू करना लेख पढ़ें.

डेमो खाते की मदद से, इस फ़्लो को आज़माया जा सकता है:

• Issuer डेमो में, आपको एक नकली ईमेल खाता और सेशन मिलता है
• Verifier डेमो, हिस्सा लेने वाली किसी भी सेवा देने वाली कंपनी की पुष्टि करेगा

ध्यान दें: Gmail, ऑरिजिन ट्रायल में सेवा देने वाली कंपनी के तौर पर हिस्सा ले रहा है. बिना किसी अतिरिक्त कॉन्फ़िगरेशन के, किसी भी @gmail.com पते से पुष्टि करने वाले फ़्लो को टेस्ट किया जा सकता है.

ईमेल पते की पुष्टि करने का फ़्लो

यहां दिए गए सेक्शन में बताया गया है कि ईमेल पते की पुष्टि करने का फ़्लो शुरू करने के लिए, आपको और आपके उपयोगकर्ताओं को क्या करना होगा. साथ ही, Email Verification Protocol का इस्तेमाल करते समय, पूरे वर्कफ़्लो के बारे में भी बताया गया है.

मुख्य शब्द

Email Verification API के मुख्य शब्द यहां दिए गए हैं:

• सत्यापनकर्ता: वह साइट जो ईमेल पता इकट्ठा करती है और उसकी पुष्टि करना चाहती है Verifier को Relying Party भी कहा जाता है.
• ईमेल प्रदाता: वह सेवा जो उपयोगकर्ता का ईमेल पता उपलब्ध कराती है. उदाहरण के लिए gmail.com.
• जारीकर्ता: वह सेवा जो उपयोगकर्ता के ईमेल के लिए खाते को मैनेज करती है. उदाहरण के लिए, accounts.google.com. Issuer को Identity Provider भी कहा जाता है.

कुछ मामलों में, ईमेल की सेवा देने वाली कंपनी और Issuer, एक ही डोमेन से काम कर सकते हैं. हालांकि, ईमेल पते का होना और उससे जुड़े खाते के लिए चालू सेशन होना, इन दोनों के बीच अंतर करना ज़रूरी है.

ईमेल पते की पुष्टि करने वाले फ़्लो का आर्किटेक्चर

ज़रूरी शर्तें

• उपयोगकर्ता ने, उसी ब्राउज़र प्रोफ़ाइल पर ईमेल की सेवा देने वाली कंपनी या Issuer में साइन इन किया हो. उदाहरण के लिए, अगर वे Gmail का इस्तेमाल करते हैं, तो उन्होंने अपने Google खाते में साइन इन किया हो.
• Verifier साइट के तौर पर, आपको ऑरिजिन ट्रायल के लिए साइन अप करना होगा. साथ ही, ईमेल फ़ॉर्म वाले पेज पर टोकन देना होगा.

• उपयोगकर्ता को, ऑटोमैटिक भरने या अपने-आप पूरा होने वाले ड्रॉप-डाउन से अपना ईमेल पता चुनना होगा.

  • अगर उपयोगकर्ता ने पहले फ़ील्ड में कोई ईमेल पता डाला है, तो वह अपने-आप पूरा होने वाले सुझाव के तौर पर दिखेगा.

  • अगर उपयोगकर्ता ने Chrome की सेटिंग "ऑटोमैटिक भरने और पासवर्ड" (chrome://settings/autofill) का इस्तेमाल करके अपना ईमेल पता जोड़ा है, तो वह ऑटोमैटिक भरने वाले सुझाव के तौर पर दिखेगा.

    ध्यान दें: मैन्युअल तरीके से टाइप किए गए पतों के लिए सहायता, आने वाले समय में उपलब्ध कराई जाएगी.

• जब कोई उपयोगकर्ता, पहली बार ईमेल पते की पुष्टि के लिए उसे उपलब्ध कराता है, तो उसे अनुमति का प्रॉम्प्ट दिखेगा. यह हर ईमेल पते के लिए सिर्फ़ एक बार होता है.

जब उपयोगकर्ता के पास अपने ब्राउज़र में चालू सेशन होता है, तो वह प्रोसेस शुरू कर सकता है:

1. ईमेल फ़ील्ड वाले किसी फ़ॉर्म पर, उपयोगकर्ता अपने-आप पूरा होने वाले ड्रॉप-डाउन से अपना ईमेल पता चुनता है. Verifier साइट, इस अनुरोध की पुष्टि करने के लिए, फ़ॉर्म में एक छिपा हुआ फ़ील्ड उपलब्ध कराती है. इसमें हर इंस्टेंस के लिए एक नॉनस होता है.

2. इसके बाद, ब्राउज़र, ईमेल डोमेन के लिए ईमेल पते की पुष्टि करने वाला डीएनएस रिकॉर्ड वापस पाएगा. इससे ब्राउज़र, Issuer पर जाता है. इसके बाद, Issuer पुष्टि करेगा कि उसके पास उस ईमेल पते के लिए चालू सेशन है.

   ध्यान दें: इन अनुरोधों से, उपयोगकर्ता के बारे में कोई अतिरिक्त जानकारी नहीं मिलती. इस चरण के दौरान, Verifier साइट को कोई जानकारी नहीं मिलती. Issuer को सिर्फ़ यह अनुरोध दिखता है कि उपयोगकर्ता के मौजूद होने की पुष्टि की जाए. उसे यह नहीं दिखता कि किस साइट ने अनुरोध शुरू किया है.

3. इसके बाद, Issuer, पते के लिए अपना ईमेल पते की पुष्टि करने वाला टोकन (ईवीटी) उपलब्ध कराएगा. ब्राउज़र, इसे कुंजी से बाउंड JWT में जोड़ता है. इसमें ईवीटी, साइट का ऑरिजिन, और इनपुट फ़ॉर्म से मिला नॉनस शामिल होता है.

4. फ़ॉर्म सबमिट करने पर, ईवीटी पैकेज को छिपे हुए फ़ील्ड में जोड़ा जाता है और साइट को भेजा जाता है.

5. इसके बाद, Verifier साइट, इन सभी जानकारी की पुष्टि करती है: उम्मीद के मुताबिक ईमेल पता, नॉनस, और ब्राउज़र और Issuer के हस्ताक्षर.

6. उपयोगकर्ता को एक छोटी सूचना दिखती है. इसमें बताया जाता है कि ईमेल की सेवा देने वाली कंपनी ने उसके ईमेल पते की पुष्टि कर दी है.

इस प्रोसेस से, Verifier साइट को इस बात की पुष्टि मिलती है कि ईमेल पता मान्य है और मौजूदा उपयोगकर्ता का है. इसका मतलब है कि साइट, पुष्टि करने वाला ईमेल भेजने से बच सकती है.

उपयोगकर्ता, पुष्टि किए गए अपने ईमेल पतों को सेटिंग > ऑटोमैटिक भरने और पासवर्ड > संपर्क की जानकारी > पुष्टि किया गया ईमेल में जाकर मैनेज कर सकते हैं. इसके अलावा, chrome://settings/contactInfo खोलकर भी इन्हें मैनेज किया जा सकता है.

इस्तेमाल के उदाहरण से जुड़ी ज़रूरी बातें

ईमेल पते की पुष्टि करने की सुविधा, आपके मौजूदा फ़्लो में एक बेहतर सुविधा है. इससे उपयोगकर्ता को ओटीपी पाने या किसी लिंक पर क्लिक करने के लिए, आपकी साइट से बाहर नहीं जाना पड़ता. साइटें, ईमेल पते की पुष्टि करने वाले फ़ील्ड को सभी काम के फ़ॉर्म में जोड़ सकती हैं. जैसे, लॉगिन, न्यूज़लेटर के लिए साइन अप, खाता बनाना, और पासवर्ड वापस पाना. ईवीपी, सिर्फ़ तब ट्रिगर होता है, जब ब्राउज़र इसे सपोर्ट करता है. अगर सबमिट करने पर कोई कोड नहीं मिलता है या पुष्टि करने के किसी भी चरण में गड़बड़ी होती है, तो ईमेल की पुष्टि करने के डिफ़ॉल्ट फ़्लो पर वापस जाया जा सकता है. इसका मतलब यह भी है कि एपीआई के लिए, सुविधा की पहचान करने की कोई सुविधा नहीं है. Verifier साइट, ईवीटी को एक वैकल्पिक सुविधा के तौर पर मानती है. अगर यह अनुरोध में मौजूद है, तो इसे प्रोसेस किया जाता है.

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

Verifier साइट को लागू करना

ज़्यादा जानकारी के लिए, एंड-टू-एंड डेमो कोड देखें. साथ ही, Email Verification API और Email Verification Protocol के प्रस्तावों में, पुष्टि करने के चरणों के बारे में पढ़ें.

फ़ॉर्म फ़ील्ड कॉन्फ़िगर करना

पक्का करें कि आपके फ़ॉर्म फ़ील्ड में सही एट्रिब्यूट हों:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

ब्राउज़र को ईमेल पते के लिए, अपने-आप पूरा होने वाले सुझाव देने की अनुमति देने के लिए, email इनपुट के type और autocomplete एट्रिब्यूट को email पर सेट करें.

फ़ॉर्म सबमिट करने पर, नया hidden फ़ील्ड, ईमेल पते की पुष्टि करने वाले टोकन से भर जाएगा. ज़रूरी एट्रिब्यूट ये हैं:

• type="hidden" सेट करें, क्योंकि इस फ़ील्ड के लिए उपयोगकर्ता के इनपुट की ज़रूरत नहीं होती.
• nonce="rAnD0m-VaLuE" सेट करें. फ़ॉर्म सबमिट करने की पुष्टि करने के लिए, साइट को सेशन से बाउंड यूनीक नॉनस देना होगा.
• autocomplete="email-verification-token" सेट करें. ब्राउज़र, इस एट्रिब्यूट का इस्तेमाल करके, भरने के लिए फ़ील्ड की पहचान करता है.

DevTools में नेटवर्क पैनल की जांच करके, अपने फ़ॉर्म एलिमेंट की पुष्टि करें. जब कोई ईमेल पता चुना जाता है, तो आपको दिखता है कि ब्राउज़र, ईमेल की सेवा देने वाली कंपनी और Issuer के लिए, डीएनएस और उसके बाद खाते की जानकारी देखने की क्वेरी ट्रिगर करता है. ये ब्राउज़र के इंटरनल अनुरोध हैं. फ़ॉर्म सबमिट करने तक, आपकी साइट को कुछ नहीं मिलता.

ईवीटी की पुष्टि करना

ईवीटी पैकेज के हर कॉम्पोनेंट की पुष्टि करने के लिए, पांच चरण होते हैं.

1. टोकन को पार्स करें.
2. उम्मीद के मुताबिक वैल्यू की पुष्टि करें.
3. कुंजी बाइंडिंग की पुष्टि करें.
4. डीएनएस रिकॉर्ड की पुष्टि करें.
5. Issuer का पता लगाएं और ईवीटी के हस्ताक्षर की पुष्टि करें.

1. टोकन को पार्स करें

फ़ॉर्म सबमिट करने से मिले रॉ डेटा में, ईवीटी और साइन किए गए दावे, Selective Disclosure JSON Web Token (SD-JWT+KB) में होते हैं. इन्हें टिल्ड (~ वर्ण से अलग किया जाता है). आपको इन्हें अलग करना होगा. साथ ही, Javascript Object Signing and Encryption (JOSE) हेडर और पेलोड को डिकोड करना होगा. उदाहरण के लिए, Node.js के लिए jose का इस्तेमाल किया जा सकता है.

अगर example.com, [e-mail] की पुष्टि करता है, तो डिकोड किया गया पेलोड, यहां दिए गए उदाहरण जैसा दिखेगा:

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "[e-mail]",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. उम्मीद के मुताबिक वैल्यू की पुष्टि करें

पक्का करें कि पेलोड में मौजूद बुनियादी वैल्यू, आपकी दी गई वैल्यू से मेल खाती हों:

• पक्का करें कि email_verified की वैल्यू true पर सेट हो.
• पक्का करें कि email, आपके फ़ॉर्म में दिए गए ईमेल पते से मेल खाता हो.
• पक्का करें कि nonce, आपके फ़ॉर्म में दिए गए नॉनस से मेल खाता हो.
• पक्का करें कि aud, आपकी साइट के ऑरिजिन से मेल खाता हो.
• पक्का करें कि iat में हाल ही का टाइमस्टैंप हो. उदाहरण के लिए, फ़ॉर्म रेंडर होने के बाद का.

अहम जानकारी: email दावे को चुनिंदा तौर पर डिसक्लोज़ किया जा सकता है. अगर इसे चुनिंदा तौर पर डिसक्लोज़ किया जाता है, तो आपको ईमेल पते के बजाय हैश मिलता है. इसकी पुष्टि, उम्मीद के मुताबिक ईमेल पते के लिए वही हैश जनरेट करके की जा सकती है. हमारा सुझाव है कि दोनों फ़ॉर्मैट के लिए सहायता उपलब्ध कराएं.

3. कुंजी बाइंडिंग की पुष्टि करें

ब्राउज़र, लेन-देन के लिए एक अस्थायी, एफिमेरल कुंजी बनाता है. इससे यह पुष्टि होती है कि उसने टोकन पर साइन किया है. ईवीटी में मौजूद cnf (पुष्टि) दावे से इस कुंजी को एक्सट्रैक्ट करें. इसके बाद, कुंजी से बाउंड JWT की पुष्टि करने के लिए इसका इस्तेमाल करें.

इसके बाद, उम्मीद के मुताबिक हैश की गिनती करें और इसकी तुलना sd_hash दावे से करें. Node.js के इस उदाहरण में, यह गिनती करने का तरीका बताया गया है:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. डीएनएस रिकॉर्ड की पुष्टि करें

ईमेल पते के डोमेन के लिए, _email-verification डीएनएस रिकॉर्ड की पुष्टि करें. उदाहरण के लिए, [e-mail] के लिए, _email-verification.gmail.com TXT रिकॉर्ड की क्वेरी करें. इस सेवा देने वाली कंपनी के लिए, क्वेरी में खाते की सेवा देने वाली कंपनी की जगह की जानकारी मिलती है. जैसे, accounts.google.com.

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. Issuer का पता लगाएं और ईवीटी के हस्ताक्षर की पुष्टि करें

पक्का करें कि Issuer, /.well-known/email-verification संसाधन उपलब्ध कराता हो. इससे टोकन जारी करने के लिए एंडपॉइंट, साइट के लिए JSON Web Key (JWK), और साइन करने के लिए इस्तेमाल किए जा सकने वाले एल्गोरिदम मिलते हैं.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

टोकन से एक्सट्रैक्ट किए गए ईवीटी JWT की पुष्टि करने के लिए, JWK का इस्तेमाल करें. ज़्यादातर JOSE लाइब्रेरी, इस पुष्टि को मैनेज करने के लिए फ़ंक्शन उपलब्ध कराती हैं.

अगर सभी पांच चरण पूरे हो जाते हैं, तो आपने सेवा देने वाली कंपनी के हिसाब से ईमेल पते की पुष्टि कर ली है. अगर ऐसा नहीं होता है, तो उपयोगकर्ता को पुष्टि करने वाला ईमेल भेजें. इसके लिए, अपने सामान्य फ़्लो का इस्तेमाल करें.

ईमेल की सेवा देने वाली कंपनी और Issuer की सेवा लागू करना

ज़्यादा जानकारी के लिए, नकली ईमेल की सेवा देने वाली कंपनी के डेमो कोड देखें. साथ ही, Email Verification API और Email Verification Protocol के प्रस्तावों में, Issuer के चरणों के बारे में पढ़ें.

Issuer के तौर पर, आपको ऑरिजिन ट्रायल के लिए साइन अप करने या टोकन उपलब्ध कराने की ज़रूरत नहीं है. ऐसा इसलिए, क्योंकि ब्राउज़र का व्यवहार, Relying Party साइट से ट्रिगर होता है. आपको सिर्फ़ यह पक्का करना है कि उन अनुरोधों का जवाब देने के लिए, उम्मीद के मुताबिक एंडपॉइंट मौजूद हों.

Issuer की पहचान करने की सुविधा कॉन्फ़िगर करना

अगर आपके डोमेन से जुड़ा कोई ईमेल पता चुना जाता है, तो ब्राउज़र को पुष्टि करने वाले आपके एंडपॉइंट की पहचान करने की अनुमति देने के लिए, डीएनएस और .well-known एचटीटीपी एंडपॉइंट का इस्तेमाल करके अपना कॉन्फ़िगरेशन दिखाएं.

डीएनएस डेलिगेट रिकॉर्ड कॉन्फ़िगर करना

अपने ईमेल डोमेन पर, डीएनएस TXT रिकॉर्ड कॉन्फ़िगर करें. इससे पुष्टि करने का अधिकार, आपके Issuer आइडेंटिफ़ायर को डेलिगेट किया जाता है. आपके इन्फ़्रास्ट्रक्चर के आधार पर, ये आइडेंटिफ़ायर एक ही डोमेन का इस्तेमाल कर सकते हैं.

रिकॉर्ड का फ़ॉर्मैट: _email-verification.<email-domain>

ज़ोन फ़ाइल का उदाहरण:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

.well-known/email-verification एंडपॉइंट होस्ट करना

अपने Issuer डोमेन पर, /.well-known/ पाथ के तहत, JSON मेटाडेटा फ़ाइल होस्ट करें. इस फ़ाइल में, आपके जारी करने की क्षमताओं और आपके इन्फ़्रास्ट्रक्चर के साथ काम करने वाले क्रिप्टोग्राफ़िक साइनिंग एल्गोरिदम की जानकारी दी जाती है.

एंडपॉइंट: https://<issuer-domain>/.well-known/email-verification

जवाब का उदाहरण:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

.well-known/web-identity एंडपॉइंट होस्ट करना

एक और .well-known JSON संसाधन, जिसे आपने Federated Credentials (FedCM) API के तहत पहले ही लागू कर लिया होगा. इससे आपके खातों के एंडपॉइंट और लॉगिन यूआरएल के लिंक मिलते हैं.

एंडपॉइंट: https://<domain>/.well-known/web-identity

जवाब का उदाहरण:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

खातों के एंडपॉइंट का इस्तेमाल करना

FedCM API का खातों का एंडपॉइंट, फ़िलहाल साइन-इन किए गए खातों की सूची उपलब्ध कराता है. यहां दिए गए उदाहरण में, कम से कम जानकारी वाला जवाब दिखाया गया है. ज़्यादा जानकारी के लिए, Identity Provider को लागू करने की गाइड देखें.

एंडपॉइंट: .well-known/web-identity में बताया गया है

यहां जवाब का एक उदाहरण दिया गया है:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "[e-mail]",
      "given_name": "Demo"
    }
  ]
}

Login Status API के साथ इंटिग्रेट करना

उपयोगकर्ता का चालू सेशन, सेवा देने वाली कंपनी के साथ होना चाहिए. साथ ही, आपको Login Status API की मदद से, ब्राउज़र को इसकी जानकारी देनी होगी.

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

Set-Login: logged-in
Set-Login: logged-out

इसके अलावा, अपने वेब ऐप्लिकेशन के कॉन्टेक्स्ट में JavaScript का इस्तेमाल करके, स्टेटस अपडेट करें:

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

टोकन जारी करने के अनुरोधों को मैनेज करना

आपके issuance_endpoint को application/x-www-form-urlencoded POST अनुरोध मिलता है. इसमें request_token शामिल होता है.

अहम जानकारी: आने वाले समय में, अनुरोध के फ़ॉर्मैट को application/json में बदलने की योजना है. इसमें request_token का पेलोड वही रहेगा. अपने एंडपॉइंट को दोनों फ़ॉर्मैट स्वीकार करने और पार्स करने के लिए कॉन्फ़िगर करें.

यहां दिए गए सेक्शन में, टोकन जारी करने के अनुरोधों को मैनेज करने की पूरी प्रोसेस दिखाई गई है.

1. टोकन जारी करने के अनुरोध की पुष्टि करना

आने वाले ब्राउज़र पेलोड को पार्स करें और उनकी पुष्टि करें:

• तरीका: POST
• सेशन की पुष्टि करना: उपयोगकर्ता की पहले पक्ष (ग्राहक) की session/authentication कुकी की पुष्टि करें. ये कुकी, अनुरोध के साथ ट्रांसमिट की जाती हैं. इससे यह पक्का किया जा सकेगा कि चालू, अनुमति वाला आइडेंटिटी कॉन्टेक्स्ट मौजूद है.
• पैरामीटर की पुष्टि करना: request_token पैरामीटर (ब्राउज़र से जनरेट किया गया साइन किया गया JWT) एक्सट्रैक्ट करें. पक्का करें कि इसमें उम्मीद के मुताबिक एफिमेरल पब्लिक की, टारगेट ईमेल, सही ऑडियंस, और मान्य टाइमस्टैंप शामिल हो.

अहम जानकारी: Chrome में, request_token के साइन किए गए JWT को लागू करने की सुविधा को अपडेट करने की योजना है. इससे प्रस्ताव के नए वर्शन के मुताबिक, एचटीटीपी मैसेज सिग्नेचर का इस्तेमाल किया जा सकेगा. प्रस्ताव की खास जानकारी के साथ, अपडेट की गई गाइड देखें.

डिकोड किया गया टोकन कुछ ऐसा दिखेगा:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "[e-mail]",
    "email": "[e-mail]",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. टोकन के साथ जवाब देना

सेशन और अनुरोध टोकन की पुष्टि होने के बाद, पेलोड का इस्तेमाल करके, साइन किया गया Selective Disclosure JWT (SD-JWT) जनरेट करें:

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "[e-mail]",
  "email_verified": true
}

अपनी निजी कुंजी और इस्तेमाल किए जा सकने वाले एल्गोरिदम का इस्तेमाल करके, पेलोड पर साइन करें. उदाहरण के लिए, Node.js में jose का इस्तेमाल करना:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

सफलता का जवाब (एचटीटीपी 200) का उदाहरण:

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

ऑरिजिन ट्रायल से जुड़ी ज़रूरी बातें

ऑरिजिन ट्रायल, सुझाव इकट्ठा करने के लिए किए जाने वाले एक्सपेरिमेंट होते हैं. इसलिए, अगर आप Relying Party या Identity Provider के तौर पर हिस्सा लेते हैं, तो आपका इनपुट अहम है. समस्याओं की शिकायत करने के लिए, GitHub के इन रिपॉज़िटरी का इस्तेमाल करें:

• Browser Email Verification API: WICG/email-verification
• Email Verification Protocol: dickhardt/email-verification

अगर आपको Chrome के लागू करने में कोई गड़बड़ी मिलती है, तो कॉम्पोनेंट के ख़िलाफ़ गड़बड़ी की शिकायत करें:

• नई समस्या: Chromium > Blink > Identity > EVP

ऑरिजिन ट्रायल की सुविधा को चालू करना, हर जवाब के हिसाब से कंट्रोल किया जाता है. इसके लिए, आपको ओटी टोकन शामिल करना होगा. इसका मतलब है कि अगर आपको अपनी कुछ उपयोगकर्ताओं के लिए इस सुविधा को सीमित करना है, तो आपके पास इसका पूरा कंट्रोल है. उदाहरण के लिए, अगर आपके पास पहले से ही A/B टेस्टिंग फ़्रेमवर्क है, तो आप ऑरिजिन ट्रायल को उसमें इंटिग्रेट कर सकते हैं. इससे, कंट्रोल किए गए एक्सपेरिमेंट के लिए ऑडियंस चुनी जा सकती है. इसके अलावा, अगर आपके पास बीटा टेस्टिंग या अर्ली प्रीव्यू ग्रुप के उपयोगकर्ता हैं, तो हो सकता है कि आपको उनके लिए इस सुविधा को चालू करना पड़े. इस मामले में, टोकन जारी करने या उसकी पुष्टि करने से पहले, दिए गए ईमेल पते की जांच करें.

ऑरिजिन ट्रायल में, ट्रैफ़िक की सीमाएं भी होती हैं. इससे, लॉन्च से पहले साइटों को इस सुविधा पर निर्भर होने से रोका जा सकता है. Issuer API पर काम किया जा रहा है. आपको Chrome के यूएक्स में अपडेट के साथ-साथ, पीछे की ओर काम न करने वाले बदलाव भी देखने को मिल सकते हैं.

डेवलपमेंट की प्रोसेस आगे बढ़ने पर, हम ब्लॉग पर और [e-mail] मेलिंग सूची पर, आगे के अपडेट पोस्ट करेंगे.