Ajoutez l’authentification à votre application Next Auth

Ce guide vous montrera comment intégrer Logto dans votre application Next.js avec Next Auth.

astuce

• Dans ce guide, nous supposons que vous avez configuré Next Auth dans votre projet Next.js. Si ce n'est pas le cas, consultez la documentation de Next Auth pour commencer.

Prérequis

• Un compte Logto Cloud ou un Logto auto-hébergé.
• Une application traditionnelle Logto créée.
• Un projet Next.js avec Next Auth, consultez la documentation Next Auth.

Intégration

Configurer le fournisseur Next Auth

Avant de plonger dans les détails, voici un aperçu rapide de l'Expérience utilisateur. Le processus de connexion peut être simplifié comme suit :

1. Votre application lance la méthode de connexion.
2. L'utilisateur est redirigé vers la page de connexion Logto. Pour les applications natives, le navigateur système est ouvert.
3. L'utilisateur se connecte et est redirigé vers votre application (configurée comme l'URI de redirection).

Concernant la connexion basée sur la redirection

1. Ce processus d'authentification (Authentication) suit le protocole OpenID Connect (OIDC), et Logto applique des mesures de sécurité strictes pour protéger la connexion utilisateur.
2. Si vous avez plusieurs applications, vous pouvez utiliser le même fournisseur d’identité (Logto). Une fois que l'utilisateur se connecte à une application, Logto complétera automatiquement le processus de connexion lorsque l'utilisateur accède à une autre application.

Pour en savoir plus sur la logique et les avantages de la connexion basée sur la redirection, consultez Expérience de connexion Logto expliquée.

---

remarque

Dans les extraits de code suivants, nous supposons que votre application fonctionne sur http://localhost:3000/.

Configurer l'URI de redirection de connexion

Passons à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection http://localhost:3000/api/auth/callback/logto et cliquez sur "Enregistrer les modifications".

Configurer le fournisseur Next Auth

astuce

Vous pouvez trouver et copier le "Secret de l'application" depuis la page des détails de l'application dans la Console d'administration :

Modifiez votre configuration de route API de Next Auth, si vous utilisez Pages Router, le fichier est dans pages/api/auth/[...nextauth].js, si vous utilisez App Router, le fichier est dans app/api/auth/[...nextauth]/route.ts.

Voici un exemple de App Router :

Next Auth v5

import NextAuth from 'next-auth';

export const {
  handlers: { GET, POST },
  signIn,
  signOut,
  auth,
} = NextAuth({
  providers: [
    {
      id: 'logto',
      name: 'Logto',
      type: 'oidc',
      // Vous pouvez obtenir la valeur de l'émetteur depuis la page Détails de l'application Logto,
      // dans le champ "Endpoint de l'émetteur"
      issuer: 'https://xxxx.logto.app/oidc',
      clientId: '<logto-app-id>',
      clientSecret: '<logto-app-secret>',
      authorization: {
        params: { scope: 'openid offline_access profile email' },
      },
      profile(profile) {
        // Vous pouvez personnaliser le mappage du profil utilisateur ici
        return {
          id: profile.sub,
          name: profile.name ?? profile.username,
          email: profile.email,
          image: profile.picture,
        };
      },
    },
  ],
});

1. Remplacez l'URL issuer par le "Endpoint de l'émetteur" de votre application Logto.
2. Remplacez le clientId et le clientSecret par l'ID et le secret de votre application Logto.
3. Personnalisez la fonction profile pour mapper le profil utilisateur à l'objet utilisateur Next Auth, le mappage par défaut est montré dans l'exemple.

Next Auth v4

import NextAuth from 'next-auth';

const handler = NextAuth({
  providers: [
    {
      id: 'logto',
      name: 'Logto',
      type: 'oauth',
      // Vous pouvez obtenir l'URL bien connue depuis la page Détails de l'application Logto,
      // dans le champ "Endpoint de configuration du fournisseur OpenID"
      wellKnown: 'https://xxxx.logto.app/oidc/.well-known/openid-configuration',
      authorization: { params: { scope: 'openid offline_access profile email' } },
      clientId: '<logto-app-id>',
      clientSecret: '<logto-app-secret>',
      client: {
        id_token_signed_response_alg: 'ES384',
      },
      profile(profile) {
        // Vous pouvez personnaliser le mappage du profil utilisateur ici
        return {
          id: profile.sub,
          name: profile.name ?? profile.username,
          email: profile.email,
          image: profile.picture,
        };
      },
    },
  ],
});

export { handler as GET, handler as POST };

1. Remplacez l'URL wellKnown par le "Endpoint de configuration du fournisseur OpenID" de votre application Logto.
2. Remplacez le clientId et le clientSecret par l'ID et le secret de votre application Logto.
3. Personnalisez la fonction profile pour mapper le profil utilisateur à l'objet utilisateur Next Auth, le mappage par défaut est montré dans l'exemple.
4. N'oubliez pas de définir le id_token_signed_response_alg sur ES384.

Point de contrôle

Maintenant, vous pouvez tester votre application pour voir si l'authentification fonctionne comme prévu.

Portées et revendications

Logto utilise les conventions de portées et revendications OIDC pour définir les Portées et Revendications pour récupérer les informations utilisateur à partir du Jeton d’identifiant et du point de terminaison OIDC userinfo. Les termes "Portée" et "Revendication" proviennent des spécifications OAuth 2.0 et OpenID Connect (OIDC).

En bref, lorsque vous demandez une Portée, vous obtiendrez les Revendications correspondantes dans les informations utilisateur. Par exemple, si vous demandez la portée `email`, vous obtiendrez les données `email` et `email_verified` de l'utilisateur.

Par défaut, le SDK Logto demandera toujours trois Portées : `openid`, `profile` et `offline_access`, et il n'est pas possible de supprimer ces Portées par défaut. Mais vous pouvez ajouter plus de Portées lors de la configuration de Logto :

const handler = NextAuth({
  providers: [
    {
      id: 'logto',
      name: 'Logto',
      // ... other options
      authorization: { params: { scope: 'openid offline_access profile email' } },
      // ... other options
    },
  ],
});

Voici la liste des Portées (Scopes) prises en charge et les Revendications (Claims) correspondantes :

openid

Nom de la revendication	Type	Description	Besoin d'userinfo ?
sub	string	L'identifiant unique de l'utilisateur	Non

profile

Nom de la revendication	Type	Description	Besoin d'userinfo ?
name	string	Le nom complet de l'utilisateur	Non
username	string	Le nom d'utilisateur de l'utilisateur	Non
picture	string	URL de la photo de profil de l'utilisateur final. Cette URL DOIT faire référence à un fichier image (par exemple, un fichier image PNG, JPEG ou GIF), plutôt qu'à une page Web contenant une image. Notez que cette URL DOIT spécifiquement référencer une photo de profil de l'utilisateur final adaptée à l'affichage lors de la description de l'utilisateur final, plutôt qu'une photo arbitraire prise par l'utilisateur final.	Non
created_at	number	Heure à laquelle l'utilisateur final a été créé. Le temps est représenté comme le nombre de millisecondes depuis l'époque Unix (1970-01-01T00:00:00Z).	Non
updated_at	number	Heure à laquelle les informations de l'utilisateur final ont été mises à jour pour la dernière fois. Le temps est représenté comme le nombre de millisecondes depuis l'époque Unix (1970-01-01T00:00:00Z).	Non

D'autres revendications standard incluent family_name, given_name, middle_name, nickname, preferred_username, profile, website, gender, birthdate, zoneinfo, et locale seront également incluses dans la portée profile sans avoir besoin de demander le point de terminaison userinfo. Une différence par rapport aux revendications ci-dessus est que ces revendications ne seront renvoyées que lorsque leurs valeurs ne sont pas vides, tandis que les revendications ci-dessus renverront null si les valeurs sont vides.

remarque

Contrairement aux revendications standard, les revendications created_at et updated_at utilisent des millisecondes au lieu de secondes.

email

Nom de la revendication	Type	Description	Besoin d'userinfo ?
email	string	L'adresse e-mail de l'utilisateur	Non
email_verified	boolean	Si l'adresse e-mail a été vérifiée	Non

phone

Nom de la revendication	Type	Description	Besoin d'userinfo ?
phone_number	string	Le numéro de téléphone de l'utilisateur	Non
phone_number_verified	boolean	Si le numéro de téléphone a été vérifié	Non

address

Veuillez vous référer à OpenID Connect Core 1.0 pour les détails de la revendication d'adresse.

custom_data

Nom de la revendication	Type	Description	Besoin d'userinfo ?
custom_data	object	Les données personnalisées de l'utilisateur	Oui

identities

Nom de la revendication	Type	Description	Besoin d'userinfo ?
identities	object	Les identités liées de l'utilisateur	Oui
sso_identities	array	Les identités SSO liées de l'utilisateur	Oui

urn:logto:scope:organizations

Nom de la revendication	Type	Description	Besoin d'userinfo ?
organizations	string[]	Les identifiants d'organisation auxquels l'utilisateur appartient	Non
organization_data	object[]	Les données d'organisation auxquelles l'utilisateur appartient	Oui

urn:logto:scope:organization_roles

Nom de la revendication	Type	Description	Besoin d'userinfo ?
organization_roles	string[]	Les rôles d'organisation auxquels l'utilisateur appartient avec le format <organization_id>:<role_name>	Non

---

En considérant la performance et la taille des données, si "Besoin d'userinfo ?" est "Oui", cela signifie que la revendication n'apparaîtra pas dans le Jeton d’identifiant (ID token), mais sera renvoyée dans la réponse du point de terminaison userinfo.

Lectures complémentaires

Flux utilisateur final : flux d'authentification, flux de compte et flux d'organisation Configurer les connecteurs Protéger votre API