Authentification Next.js : démarrage rapide

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

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 existant pour la vérification et le guide de soumission de transactions 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 pour le contrat de validation.

Guides