> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# JavaScript प्रमाणीकरण क्विकस्टार्ट

> Didit में सक्षम प्रमाणीकरण एप्लिकेशन को PKCE के साथ होस्टेड साइन-इन से जोड़ें, जिसमें कॉलबैक सत्यापन, सत्र जाँच और लॉगआउट शामिल हैं।

> [!WARNING]
>
> प्रमाणीकरण नया है: इस होस्टेड-फ़्लो उदाहरण का उपयोग ऐसे एप्लिकेशन के साथ करें जिसमें प्रमाणीकरण चालू है। `@didit-protocol/auth` पैकेज अभी प्रकाशित नहीं हुआ है; नीचे दिया गया पैकेज API एक प्रीव्यू है, इंस्टॉल किया जा सकने वाला क्विकस्टार्ट नहीं।

## होस्टेड साइन-इन कॉन्फ़िगर करें

अपने सैंडबॉक्स एप्लिकेशन के लिए ठीक वही कॉलबैक URL और अपना वेब origin रजिस्टर करें। कंसोल से इसका साइन-इन origin (`https://<slug>.sandbox.auth.didit.me`) कॉपी करें, जैसा [ओवरव्यू](https://docs.didit.me/hi/authentication/overview.md) में बताया गया है। यह उदाहरण ब्राउज़र की क्रिप्टोग्राफ़ी APIs का उपयोग करता है और HTTPS आवश्यक है, या सैंडबॉक्स में localhost का उपयोग करें: क्या रजिस्टर करना है, यह जानने के लिए [लोकल डेवलपमेंट](https://docs.didit.me/hi/authentication/overview.md#लोकल-डेवलपमेंट) देखें।

`state` और PKCE verifier का स्वामित्व एप्लिकेशन के पास है। पासवर्ड, ईमेल, पासकी, फ़ोन, SSO और आवश्यक MFA स्क्रीन होस्टेड साइन-इन द्वारा नियंत्रित की जाती हैं। इस कोड में कोई API कुंजी नहीं होनी चाहिए।

```javascript auth.js theme={null}
// Replace both values with your registered application configuration.
const AUTH_BASE = "https://YOUR_SLUG.sandbox.auth.didit.me/";
const REDIRECT_URI = "https://YOUR_APP_ORIGIN/auth/callback";
const PENDING = "didit.auth.pending";
let tokens = null;

function base64url(bytes) {
  return btoa(String.fromCharCode(...bytes))
    .replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
}

export async function signIn() {
  const verifier = base64url(crypto.getRandomValues(new Uint8Array(32)));
  const state = base64url(crypto.getRandomValues(new Uint8Array(32)));
  const digest = await crypto.subtle.digest("SHA-256", new TextEncoder().encode(verifier));
  sessionStorage.setItem(PENDING, JSON.stringify({ verifier, state, startedAt: Date.now() }));
  const url = new URL("sign-in", AUTH_BASE);
  url.search = new URLSearchParams({
    redirect_uri: REDIRECT_URI,
    state,
    code_challenge: base64url(new Uint8Array(digest)),
    code_challenge_method: "S256",
  }).toString();
  window.location.assign(url.href);
}

export async function handleCallback() {
  const query = new URLSearchParams(window.location.search);
  const saved = sessionStorage.getItem(PENDING);
  sessionStorage.removeItem(PENDING);
  history.replaceState(null, "", window.location.pathname);
  if (!saved) throw new Error("Start sign-in again.");
  const pending = JSON.parse(saved);
  if (query.get("state") !== pending.state || Date.now() - pending.startedAt > 600000) {
    throw new Error("Invalid or expired sign-in. Start again.");
  }
  if (query.has("error") || !query.get("code")) throw new Error("Sign-in was not completed.");
  const response = await fetch(new URL("token/", AUTH_BASE), {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      grant_type: "authorization_code",
      code: query.get("code"),
      code_verifier: pending.verifier,
      redirect_uri: REDIRECT_URI,
    }),
  });
  if (!response.ok) throw new Error("Code exchange failed. Start sign-in again.");
  tokens = await response.json();
  return getSession();
}

export async function getSession() {
  if (!tokens) return null;
  const response = await fetch(new URL("session/", AUTH_BASE), {
    headers: { Authorization: `Bearer ${tokens.access_token}` },
    cache: "no-store",
  });
  if (!response.ok) {
    tokens = null;
    throw new Error("Session check failed. Sign in again.");
  }
  return response.json();
}

export async function signOut() {
  const current = tokens;
  tokens = null;
  if (!current) return;
  const response = await fetch(new URL("session/", AUTH_BASE), {
    method: "DELETE",
    headers: { Authorization: `Bearer ${current.access_token}` },
  });
  if (response.status !== 204) throw new Error("Local state cleared; server logout failed.");
}
```

अपने साइन-इन बटन से `signIn()` कॉल करें। पंजीकृत कॉलबैक पेज पर `handleCallback()` को एक बार कॉल करें, एक लोडिंग स्थिति दिखाएँ, और विफल होने पर उसकी त्रुटि दिखाएँ। वर्तमान उपयोगकर्ता के लिए `getSession()` और लॉगआउट के लिए `signOut()` उपयोग करें। कॉलबैक अनुरोध करने से पहले अपना code एड्रेस बार से हटा देता है।

यह न्यूनतम उदाहरण टोकन मेमोरी में रखता है और पेज रीलोड होने या access token की समय-सीमा समाप्त होने के बाद फिर से साइन इन करवाता है। स्थायी सत्र के लिए, अपने बैकएंड का उपयोग करें और सुरक्षित cookies या सीरियलाइज़्ड [refresh rotation](https://docs.didit.me/hi/authentication/tokens-and-jwks.md) लागू करें। Refresh tokens को कभी URLs या logs में न डालें। फ़्रंटएंड सत्र जाँच केवल प्रस्तुति को नियंत्रित करती है; आपके बैकएंड को हर सुरक्षित अनुरोध पर कॉल करने वाले की पुष्टि करनी होगी।

## प्रमाणीकरण SDK रिलीज़ प्रीव्यू

प्रस्तावित `@didit-protocol/auth` कोर `createDiditAuth({publishableKey})`, `signIn()`, `handleRedirectCallback()`, `getSession()`, `getToken()`, `onAuthStateChange` और `signOut()` उपलब्ध कराता है, और identity में `vendorData` भी शामिल है। इसका उद्देश्य स्वचालित डिवाइस सिग्नल जोड़ना और `verifyToken()` के साथ एक सर्वर एंट्री पॉइंट जोड़ना है।

Publishable key `pk_live_` (लाइव एप्लिकेशन) या `pk_test_` (सैंडबॉक्स एप्लिकेशन) होती है, इसके बाद आपके एप्लिकेशन के origin का base64url encoding होता है, बिना padding के।
SDK अपने API कॉल उसी origin पर भेजता है।
Key सार्वजनिक है: यह एप्लिकेशन की पहचान करती है और कोई secret नहीं है।

### प्रीव्यू में Step-up और पुनः प्रमाणीकरण

* `stepUp({ action, amount?, currency?, redirectUri? })` आपके एप्लिकेशन के `POST step-up/` को कॉल करता है, यह पूछने के लिए कि क्या `action` को पहचान जाँच की आवश्यकता है।
  `action` `payout`, `bank` या `contact` है, और payout के लिए `amount` आवश्यक है।
  जब आपका कोई step-up नियम लागू होता है, तो यह Didit द्वारा लौटाए गए verification पेज पर नेविगेट करता है।
* `handleStepUpCallback(url?)` उस पेज पर चलता है जहाँ व्यक्ति वापस आता है।
  यह `?step_up=<id>` पढ़ता है, इसे एड्रेस बार से हटाता है, और `GET step-up/{id}/` से परिणाम पढ़ता है।
* `reauthenticate({ method? })` उसी व्यक्ति को होस्टेड पेज पर (`method: "redirect"`, डिफ़ॉल्ट) या पासकी से (`method: "passkey"`, केवल आपके एप्लिकेशन के Didit साइन-इन डोमेन पर) फिर से साइन इन करवाता है।
  होस्टेड पेज के बाद, इसे `handleRedirectCallback()` से पूरा करें।
  यदि कोई दूसरा व्यक्ति इसे पूरा करता है, तो यह `step_up_user_mismatch` के साथ reject हो जाता है और मूल सत्र बना रहता है।

दोनों step-up methods `{ id, status, approved, rule, method }` के साथ resolve होते हैं, जहाँ `status` `not_required`, `pending`, `approved`, `review`, `declined` या `expired` है।
`redirectUri` क्लाइंट के redirect पते पर डिफ़ॉल्ट होता है और आपके एप्लिकेशन के पंजीकृत redirect पतों में से किसी एक से ठीक मेल खाना चाहिए: जब जाँच आवश्यक हो, तो Didit किसी भी अन्य पते को अस्वीकार करता है।
आपका बैकएंड step-up के आधार पर कार्य करने से पहले, `GET step-up/{id}/` और व्यक्ति के access token के साथ step-up को फिर से पढ़ता है, क्योंकि ब्राउज़र द्वारा रिपोर्ट किए गए परिणाम को बदला जा सकता है।

headless साइन-इन `protection_required` भी लौटा सकता है, जब आपके एप्लिकेशन के protection नियम उसे चिह्नित करें।
तब व्यक्ति इसे उस code से पूरा करता है जो Didit ने उसे ईमेल किया है (`protection.verify({ code })`) या पासकी से (`protection.passkey()`), और `methods` बताता है कि वह इन दोनों में से कौन-सी विधि इस्तेमाल कर सकता है।

कोई अनुमानित version इंस्टॉल न करें और अनुमानित कॉलबैक विकल्पों के अनुसार कोड न लिखें। होस्टेड उदाहरण बदलने से पहले प्रकाशित पैकेज के exports, issuer और key configuration की पुष्टि करें। पासवर्ड, ईमेल code, magic link, पासकी, फ़ोन, MFA, सोशल साइन-इन, step-up और agent methods उस रिलीज़ के समर्थित API पर निर्भर करेंगे।

## अन्य उत्पाद जोड़ें

आपका बैकएंड access token की पुष्टि करता है (देखें [टोकन और JWKS](https://docs.didit.me/hi/authentication/tokens-and-jwks.md)) और उसका `vendor_data` पढ़ता है। उस मान को [सत्यापन सत्र बनाते समय](https://docs.didit.me/hi/sessions-api/create-session.md) या [लेन-देन टोकन जारी करते समय](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md) `vendor_data` के रूप में उपयोग करें। सफल साइन-इन का अर्थ यह नहीं है कि किसी भी उत्पाद ने उपयोगकर्ता को स्वीकृत किया है।

शिप करने से पहले, अपने सक्षम sandbox एप्लिकेशन के विरुद्ध sign-up, लौटने वाले उपयोगकर्ता का साइन-इन, रद्द करना, state का मेल न खाना, पुनः उपयोग किया गया code, पासवर्ड भूल जाना, MFA, समय-सीमा समाप्त होना और लॉगआउट का परीक्षण करें।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.