Ajoutez l’authentification à votre application Passport.js
Ce guide vous montrera comment intégrer Logto dans votre application avec Passport.js et la stratégie OIDC.
- Dans ce guide, nous supposons que vous avez configuré Express avec session dans votre projet. Si ce n'est pas le cas, consultez le site web Express.js pour commencer.
Prérequis
- Un compte Logto Cloud ou un Logto auto-hébergé.
- Une application traditionnelle Logto créée.
- Un projet express avec session configurée. Consultez le site web Express.js.
Installation
Installez le SDK Logto via votre gestionnaire de paquets préféré :
- npm
- pnpm
- yarn
npm i passport passport-openidconnect
pnpm add passport passport-openidconnect
yarn add passport passport-openidconnect
Intégration
Initialiser Passport.js avec la stratégie OIDC
import passport from 'passport';
import OpenIDConnectStrategy, { type Profile, type VerifyCallback } from 'passport-openidconnect';
const endpoint = '<your-logto-endpoint>';
const appId = '<your-application-id>';
const appSecret = '<your-application-secret>';
export default function initPassport() {
passport.use(
new OpenIDConnectStrategy(
{
issuer: `${endpoint}/oidc`,
authorizationURL: `${endpoint}/oidc/auth`,
tokenURL: `${endpoint}/oidc/token`,
userInfoURL: `${endpoint}/oidc/me`,
clientID: appId,
clientSecret: appSecret,
callbackURL: '/callback',
scope: ['profile', 'offline_access'],
},
(issuer: string, profile: Profile, callback: VerifyCallback) => {
callback(null, profile);
}
)
);
passport.serializeUser((user, callback) => {
callback(null, user);
});
passport.deserializeUser(function (user, callback) {
callback(null, user as Express.User);
});
}
Ce code initialise Passport avec la OpenIDConnectStrategy
. Les méthodes serialize et deserialize sont définies à des fins de démonstration.
Assurez-vous d'initialiser et d'attacher le middleware Passport dans votre application :
import initPassport from './passport';
// ... autre code
initPassport();
// ... autre code
app.use(passport.authenticate('session'));
// ... autre code
Configurer les URIs de redirection
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 :
- Votre application lance la méthode de connexion.
- L'utilisateur est redirigé vers la page de connexion Logto. Pour les applications natives, le navigateur système est ouvert.
- 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
- 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.
- 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.
Dans les extraits de code suivants, nous supposons que votre application fonctionne sur http://localhost:3000/
.
Configurer les URIs de redirection
Passez à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection http://localhost:3000/callback
.
Tout comme pour la connexion, les utilisateurs doivent être redirigés vers Logto pour se déconnecter de la session partagée. Une fois terminé, il serait idéal de rediriger l'utilisateur vers votre site web. Par exemple, ajoutez http://localhost:3000/
comme section d'URI de redirection après déconnexion.
Ensuite, cliquez sur "Enregistrer" pour sauvegarder les modifications.
Implémenter la connexion et la déconnexion
Nous allons maintenant créer des routes spécifiques pour les processus d'authentification :
app.get('/sign-in', passport.authenticate('openidconnect'));
app.get(
'/callback',
passport.authenticate('openidconnect', {
successReturnToOrRedirect: '/',
})
);
app.get('/sign-out', (request, response, next) => {
request.logout((error) => {
if (error) {
next(error);
return;
}
response.redirect(`${endpoint}/oidc/session/end?client_id=${appId}`);
});
});
Puis ajoutez à la page d'accueil
app.get('/', (request: Request, response) => {
const { user } = request;
response.setHeader('content-type', 'text/html');
if (user) {
response.end(
`<h1>Bonjour Logto</h1><p>Connecté en tant que ${JSON.stringify(
user
)}, <a href="/sign-out">Déconnexion</a></p>`
);
} else {
response.end(`<h1>Bonjour Logto</h1><p><a href="/sign-in">Connexion</a></p>`);
}
});
Point de contrôle : Testez votre application
Maintenant, vous pouvez tester votre application :
- Exécutez votre application, vous verrez le bouton de connexion.
- Cliquez sur le bouton de connexion, le SDK initiera le processus de connexion et vous redirigera vers la page de connexion Logto.
- Après vous être connecté, vous serez redirigé vers votre application et verrez le bouton de déconnexion.
- Cliquez sur le bouton de déconnexion pour effacer le stockage local et vous déconnecter.
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 :
export default function initPassport() {
passport.use(
new OpenIDConnectStrategy(
{
// ... other options
clientID: appId,
clientSecret: appSecret,
callbackURL: '/callback',
scope: ['openid', 'offline_access', 'profile', 'email'],
}
// ... other options
)
);
// ... 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.
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 ? |
---|---|---|---|
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.