> ## 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.

# Next.js क्विकस्टार्ट

> Didit के साथ Next.js में सर्वर-नियंत्रित प्रमाणीकरण सत्र की योजना बनाएं: PKCE कॉलबैक, HttpOnly कुकीज़ और सुरक्षित अनुरोधों पर प्राधिकरण।

> [!WARNING]
>
> प्रमाणीकरण नया है: `@didit-protocol/auth-nextjs` और core server verifier रिलीज़ पर निर्भर हैं। पैकेज रिलीज़ से पहले कोई middleware import path, cookie name या `auth()` return shape तय नहीं है। Access tokens ES256 JWTs हैं: इन्हें अपने एप्लिकेशन के JWKS से सत्यापित करें, और जब यह जानना हो कि सत्र अब भी सक्रिय है, तब `GET session/` कॉल करें।

## अपने सर्वर पर सत्र बनाए रखें

server-rendered एप्लिकेशन के लिए निम्नलिखित बदलावों के साथ, [JavaScript quickstart](https://docs.didit.me/hi/authentication/quickstarts/javascript.md) में बताया गया होस्टेड फ़्लो उपयोग करें। आपके route names एप्लिकेशन routes हैं जिन्हें आप स्वयं लागू करते हैं, Didit API endpoints नहीं।

| एप्लिकेशन route | ज़िम्मेदारी |
| - | - |
| साइन-इन शुरू करें | state और S256 PKCE बनाएँ; लेन-देन को अल्पकालिक सर्वर सत्र में संग्रहीत करें; `{origin}/sign-in` पर रीडायरेक्ट करें। |
| पंजीकृत callback | state और समाप्ति की जाँच करें, लेन-देन को एक बार उपयोग करें, `token/` पर code का आदान-प्रदान करें, और tokens को सर्वर-साइड पर संग्रहीत करें। |
| सुरक्षित पेज या API route | अपनी सत्र cookie पढ़ें और end-user access token को अपने JWKS से सत्यापित करें, या जब निरस्तीकरण तुरंत प्रभावी होना ज़रूरी हो तो `session/` पर सत्यापित करें; उस व्यक्ति के लिए अनुरोधित कार्रवाई को अधिकृत करें। |
| Refresh | प्रति सत्र refresh को क्रमबद्ध करें, `token/` कॉल करें, और token pair को परमाणु रूप से बदलें। |
| Sign-out | CSRF-संरक्षित mutation जो `session/` को निरस्त करता है और एप्लिकेशन सत्र को साफ़ करता है। |

केवल एक यादृच्छिक एप्लिकेशन-सत्र reference को `Secure`, `HttpOnly`, `SameSite=Lax` cookie में भेजें, जिसका path सीमित हो। उचित समाप्ति अवधि रखें और साइन-इन के बाद reference बदलें। Didit refresh token को rendered props, client components या browser storage में उजागर न करें। token और callback responses पर `Cache-Control: no-store` उपयोग करें।

केवल layout या middleware की जाँच पर भरोसा न करें: हर डेटा access और mutation पर अधिकृत करें। cookie से प्रमाणित mutations को CSRF से सुरक्षित रखें। केवल कॉन्फ़िगर किए गए लॉगिन-के-बाद के गंतव्यों की अनुमति दें, query string से आने वाले किसी भी मनमाने `returnTo` URL की कभी नहीं।

## पैकेज रिलीज़ पूर्वावलोकन

प्रस्तावित पैकेज में middleware, server-side `auth()`, callback route और server rendering के लिए HttpOnly cookie समर्थन जुड़ेगा। core `/server` entry का उद्देश्य cached JWKS के साथ `verifyToken()` देना है। इन symbols का उपयोग करने से पहले सत्यापित रिलीज़ के exports की प्रतीक्षा करें। तब तक, [tokens and JWKS](https://docs.didit.me/hi/authentication/tokens-and-jwks.md) में बताए अनुसार, किसी भी JOSE library से tokens स्वयं सत्यापित करें।

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

सर्वर पर सत्यापन सत्र बनाएँ और सीमित दायरे वाले monitoring tokens जारी करें। `vendor_data` को सत्यापित व्यक्ति मैपिंग से प्राप्त करें। ब्राउज़र को केवल सत्यापन सत्र URL या अल्पकालिक SDK token लौटाएँ। `DIDIT_API_KEY` को सार्वजनिक environment variables में न रखें।

सत्यापन के लिए मौजूदा [web verification SDK](https://docs.didit.me/hi/integration/web-sdks/javascript-sdk.md) और monitoring के लिए [transaction submission guide](https://docs.didit.me/hi/transaction-monitoring/sdk-transaction-submission.md) का उपयोग करें। इनमें से कोई भी प्रमाणीकरण सत्र प्रबंधक नहीं है।

रिलीज़ से पहले callback replay, गलत state, समय-सीमा समाप्त state, refresh races, निरस्त सत्र, CSRF अस्वीकृति और लॉगआउट का परीक्षण करें। सत्यापन अनुबंध के लिए [tokens and JWKS](https://docs.didit.me/hi/authentication/tokens-and-jwks.md) देखें।


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