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

# Authentification Next.js : démarrage rapide

> Planifiez une session d'authentification gérée côté serveur avec Didit : callbacks PKCE, cookies HttpOnly et autorisation sur les requêtes protégées.

> [!WARNING]
>
> L'authentification est une nouveauté : `@didit-protocol/auth-nextjs` et le vérificateur serveur principal dépendent de la version publiée. Aucun chemin d'import de middleware, nom de cookie ni forme de retour de `auth()` n'est imposé avant la publication du package. Les tokens d'accès sont des JWT ES256 : vérifiez-les avec le JWKS de votre application, et appelez `GET session/` lorsque vous devez savoir que la session est toujours active.

## Conserver la session sur votre serveur

Utilisez le flux hébergé décrit dans le [démarrage rapide JavaScript](https://docs.didit.me/fr/authentication/quickstarts/javascript.md), avec les modifications suivantes pour une application à rendu côté serveur. Vos noms de routes sont des routes d'application que vous implémentez, et non des endpoints de l'API Didit.

| Route de l'application | Responsabilité |
| - | - |
| Démarrer la connexion | Générer le state et le PKCE S256 ; stocker la transaction dans une session serveur à courte durée de vie ; rediriger vers `{origin}/sign-in`. |
| Callback enregistré | Valider le state et l'expiration, consommer la transaction une seule fois, échanger le code en appelant `token/`, et stocker les tokens côté serveur. |
| Page ou route d'API protégée | Lire votre cookie de session et vérifier le token d'accès de l'utilisateur final avec votre JWKS, ou appeler `session/` lorsque la révocation doit être immédiate ; autoriser l'action demandée pour cette personne. |
| Rafraîchissement | Sérialiser le rafraîchissement par session, appeler `token/`, et remplacer la paire de tokens de façon atomique. |
| Déconnexion | Mutation protégée contre le CSRF qui révoque `session/` et efface la session de l'application. |

Envoyez uniquement une référence de session applicative aléatoire dans un cookie `Secure`, `HttpOnly`, `SameSite=Lax` avec un chemin restreint. Utilisez une durée de vie appropriée et faites pivoter la référence après la connexion. N'exposez pas le token de rafraîchissement Didit dans les props rendues, les composants client ni le stockage du navigateur. Utilisez `Cache-Control: no-store` sur les réponses liées au token et au callback.

Ne vous fiez pas à une simple vérification dans un layout ou un middleware : effectuez l'autorisation lors de chaque accès aux données et de chaque mutation. Protégez les mutations authentifiées par cookie contre le CSRF. Autorisez uniquement les destinations configurées après connexion, jamais une URL `returnTo` arbitraire issue de la chaîne de requête.

## Aperçu de la version du package

Le package prévu ajoute un middleware, un `auth()` côté serveur, une route de rappel et la prise en charge des cookies HttpOnly pour le rendu serveur. Le point d'entrée `/server` du cœur vise à fournir `verifyToken()` avec un JWKS mis en cache. Attendez les exports de la version publiée et validée avant d'utiliser ces symboles. D'ici là, vérifiez les tokens vous-même avec n'importe quelle bibliothèque JOSE, comme décrit dans [tokens et JWKS](https://docs.didit.me/fr/authentication/tokens-and-jwks.md).

## Connecter les autres produits

Créez les sessions de vérification et émettez, côté serveur, des tokens de surveillance à portée limitée. Dérivez `vendor_data` à partir de la correspondance validée de la personne. Renvoyez au navigateur uniquement une URL de session de vérification ou un token SDK à courte durée de vie. Gardez `DIDIT_API_KEY` hors des variables d'environnement publiques.

Utilisez le [SDK de vérification web](https://docs.didit.me/fr/integration/web-sdks/javascript-sdk.md) existant pour la vérification et le [guide de soumission de transactions](https://docs.didit.me/fr/transaction-monitoring/sdk-transaction-submission.md) pour la surveillance. Aucun des deux n'est un gestionnaire de sessions d'authentification.

Testez avant la publication : le rejeu d'un rappel, un state incorrect, un state expiré, les conflits lors du rafraîchissement, les sessions révoquées, le rejet CSRF et la déconnexion. Consultez [tokens et JWKS](https://docs.didit.me/fr/authentication/tokens-and-jwks.md) pour le contrat de validation.


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