Ajoutez l’authentification à votre application Vanilla JS
Vanilla JS : Intégrer @logto/browser
- Le SDK vanilla-js est agnostique au framework, vous pouvez l'utiliser dans n'importe quel framework frontend en écrivant un wrapper pour l'adapter.
- Le projet d'exemple est disponible sur notre répertoire SDK.
Prérequis
- Un compte Logto Cloud ou un Logto auto-hébergé.
- Une application monopage (SPA) créée dans Logto Console.
- Un projet d'application Vanilla JS.
Installation
Choisissez votre gestionnaire de paquets préféré ou utilisez le CDN pour installer le Logto Browser SDK.
- npm
- pnpm
- yarn
- CDN
npm i @logto/browser
pnpm add @logto/browser
yarn add @logto/browser
<!-- Remerciements spéciaux à jsdelivr -->
<script type="module">
import LogtoClient from 'https://cdn.jsdelivr.net/npm/@logto/browser@2.2.13/+esm';
</script>
Intégration
Initialiser LogtoClient
Importez et initialisez une instance LogtoClient en passant la configuration :
import LogtoClient from '@logto/browser';
const logtoClient = new LogtoClient({
endpoint: '<your-logto-endpoint>',
appId: '<your-application-id>',
});
Les endpoint et appId peuvent être trouvés dans la page des détails de l'application dans la Logto Console.
Configurer les URIs de redirection
Avant d’entrer dans les détails, voici un aperçu rapide de l’expérience utilisateur finale. 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.
Gérer la redirection
Il reste encore des choses à faire après que l'utilisateur ait été redirigé vers votre application depuis Logto. Gérons cela correctement.
const callbackHandler = async (logtoClient) => {
await logtoClient.handleSignInCallback(window.location.href);
if (!logtoClient.isAuthenticated) {
// Gérer l'échec de la connexion
alert('Échec de la connexion');
return;
}
// Gérer la connexion réussie
window.location.assign('/');
};
Implémenter la connexion et la déconnexion
logtoClient fournit les méthodes signIn et signOut pour vous aider à gérer facilement le flux d'authentification (Authentication).
Avant d'appeler .signIn(), assurez-vous d'avoir correctement configuré l'URI de redirection dans la console d'administration.
const isAuthenticated = await logtoClient.isAuthenticated();
const onClickSignIn = () => {
logtoClient.signIn('http://localhost:3000/callback');
};
const onClickSignOut = () => {
logtoClient.signOut('http://localhost:3000');
};
const button = document.createElement('button');
button.innerHTML = isAuthenticated ? 'Sign Out' : 'Sign In';
button.addEventListener('click', isAuthenticated ? onClickSignOut : onClickSignIn);
document.body.appendChild(button);
Appeler .signOut() effacera toutes les données Logto en mémoire et dans le localStorage si elles existent.
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 l'ID utilisateur et le bouton de déconnexion.
- Cliquez sur le bouton de déconnexion pour vous déconnecter.
Obtenez des informations sur l'utilisateur
Afficher les informations de l'utilisateur
Pour afficher les informations de l'utilisateur, vous pouvez utiliser la méthode logtoClient.getIdTokenClaims(). Par exemple, sur votre page d'accueil :
const userInfo = await logtoClient.getIdTokenClaims();
// Générer un tableau d'affichage pour les revendications du jeton d’identifiant
const table = document.createElement('table');
const thead = document.createElement('thead');
const tr = document.createElement('tr');
const thName = document.createElement('th');
const thValue = document.createElement('th');
thName.innerHTML = 'Nom';
thValue.innerHTML = 'Valeur';
tr.append(thName, thValue);
thead.append(tr);
table.append(thead);
const tbody = document.createElement('tbody');
for (const [key, value] of Object.entries(userInfo)) {
const tr = document.createElement('tr');
const tdName = document.createElement('td');
const tdValue = document.createElement('td');
tdName.innerHTML = key;
tdValue.innerHTML = typeof value === 'string' ? value : JSON.stringify(value);
tr.append(tdName, tdValue);
tbody.append(tr);
}
table.append(tbody);
Demander des revendications supplémentaires
Il se peut que certaines informations utilisateur soient manquantes dans l'objet retourné par getIdTokenClaims(). Cela est dû au fait que OAuth 2.0 et OpenID Connect (OIDC) sont conçus pour suivre le principe du moindre privilège (PoLP), et Logto est construit sur ces normes.
Par défaut, des revendications limitées sont retournées. Si vous avez besoin de plus d'informations, vous pouvez demander des portées supplémentaires pour accéder à plus de revendications.
Une "revendication" est une affirmation faite à propos d'un sujet ; une "portée" est un groupe de revendications. Dans le cas actuel, une revendication est une information sur l'utilisateur.
Voici un exemple non normatif de la relation portée - revendication :
La revendication "sub" signifie "sujet", qui est l'identifiant unique de l'utilisateur (c'est-à-dire l'ID utilisateur).
Le SDK Logto demandera toujours trois portées : openid, profile, et offline_access.
Pour demander des portées supplémentaires, vous pouvez configurer les configurations Logto :
import LogtoClient, { UserScope } from '@logto/browser';
const logtoClient = new LogtoClient({
appId: '<your-application-id>',
endpoint: '<your-logto-endpoint>',
scopes: [UserScope.Email, UserScope.Phone],
});
Ensuite, vous pouvez accéder aux revendications supplémentaires dans la valeur de retour de logtoClient.getIdTokenClaims() :
const claims = await getIdTokenClaims();
// Vous pouvez maintenant accéder aux revendications supplémentaires `claims.email`, `claims.phone`, etc.
Revendications nécessitant des requêtes réseau
Pour éviter de surcharger le jeton d’identifiant (ID token), certaines revendications nécessitent des requêtes réseau pour être récupérées. Par exemple, la revendication custom_data n'est pas incluse dans l'objet utilisateur même si elle est demandée dans les portées. Pour accéder à ces revendications, vous pouvez utiliser la méthode logtoClient.fetchUserInfo() :
const userInfo = await logtoClient.fetchUserInfo();
// Vous pouvez maintenant accéder à la revendication `userInfo.custom_data`
Portées et revendications
Logto utilise les conventions OIDC sur les portées (scopes) et revendications (claims) pour définir les portées et revendications permettant de récupérer les informations utilisateur depuis le jeton d’identifiant (ID token) et le point de terminaison OIDC userinfo. Les termes "portée (Scope)" et "revendication (Claim)" proviennent des spécifications OAuth 2.0 et OpenID Connect (OIDC).
Pour les revendications OIDC standard, leur inclusion dans le jeton d’identifiant est strictement déterminée par les portées demandées. Les revendications étendues (telles que custom_data et organizations) peuvent être configurées en plus pour apparaître dans le jeton d’identifiant via les paramètres Jeton d’identifiant personnalisé.
Voici la liste des portées prises en charge et les revendications correspondantes :
Portées OIDC standard
openid (par défaut)
| Nom de la revendication | Type | Description |
|---|---|---|
| sub | string | L'identifiant unique de l'utilisateur |
profile (par défaut)
| Nom de la revendication | Type | Description |
|---|---|---|
| name | string | Le nom complet de l'utilisateur |
| username | string | Le nom d'utilisateur de l'utilisateur |
| picture | string | URL de la photo de profil de l'utilisateur final. Cette URL DOIT référencer un fichier image (par exemple, un fichier PNG, JPEG ou GIF), plutôt qu'une page Web contenant une image. Notez que cette URL DOIT référencer spécifiquement une photo de profil de l'utilisateur final adaptée à l'affichage lors de la description de l'utilisateur final, et non une photo quelconque prise par l'utilisateur final. |
| created_at | number | Date de création de l'utilisateur final. Le temps est représenté par le nombre de millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). |
| updated_at | number | Date de la dernière mise à jour des informations de l'utilisateur final. Le temps est représenté par le nombre de millisecondes écoulées depuis l'époque Unix (1970-01-01T00:00:00Z). |
D'autres revendications standard telles que 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 l'endpoint userinfo. Une différence par rapport aux revendications ci-dessus est que ces revendications ne seront retournées que si leurs valeurs ne sont pas vides, tandis que les revendications ci-dessus retourneront null si les valeurs sont vides.
Contrairement aux revendications standard, les revendications created_at et updated_at utilisent les millisecondes au lieu des secondes.
email
| Nom de la revendication | Type | Description |
|---|---|---|
string | L'adresse e-mail de l'utilisateur | |
| email_verified | boolean | Si l'adresse e-mail a été vérifiée |
phone
| Nom de la revendication | Type | Description |
|---|---|---|
| phone_number | string | Le numéro de téléphone de l'utilisateur |
| phone_number_verified | boolean | Si le numéro de téléphone a été vérifié |
address
Veuillez vous référer à la spécification OpenID Connect Core 1.0 pour les détails de la revendication d'adresse.
Les portées marquées (par défaut) sont toujours demandées par le SDK Logto. Les revendications sous les portées OIDC standard sont toujours incluses dans le jeton d’identifiant lorsque la portée correspondante est demandée — elles ne peuvent pas être désactivées.
Portées étendues
Les portées suivantes sont étendues par Logto et retourneront des revendications via l’endpoint userinfo. Ces revendications peuvent également être configurées pour être incluses directement dans le jeton d’identifiant via Console > JWT personnalisé. Voir Jeton d’identifiant personnalisé pour plus de détails.
custom_data
| Nom de la revendication | Type | Description | Inclus dans le jeton d’identifiant par défaut |
|---|---|---|---|
| custom_data | object | Les données personnalisées de l'utilisateur |
identities
| Nom de la revendication | Type | Description | Inclus dans le jeton d’identifiant par défaut |
|---|---|---|---|
| identities | object | Les identités liées de l'utilisateur | |
| sso_identities | array | Les identités SSO liées de l'utilisateur |
roles
| Nom de la revendication | Type | Description | Inclus dans le jeton d’identifiant par défaut |
|---|---|---|---|
| roles | string[] | Les rôles de l'utilisateur | ✅ |
urn:logto:scope:organizations
| Nom de la revendication | Type | Description | Inclus dans le jeton d’identifiant par défaut |
|---|---|---|---|
| organizations | string[] | Les identifiants d’organisation auxquels l'utilisateur appartient | ✅ |
| organization_data | object[] | Les données d’organisation auxquelles l'utilisateur appartient |
Ces revendications d’organisation peuvent également être récupérées via l’endpoint userinfo lors de l’utilisation d’un jeton opaque. Cependant, les jetons opaques ne peuvent pas être utilisés comme jetons d’organisation pour accéder à des ressources spécifiques à une organisation. Voir Jeton opaque et organisations pour plus de détails.
urn:logto:scope:organization_roles
| Nom de la revendication | Type | Description | Inclus dans le jeton d’identifiant par défaut |
|---|---|---|---|
| organization_roles | string[] | Les rôles d’organisation auxquels l'utilisateur appartient au format <organization_id>:<role_name> | ✅ |
Ressources API
Nous vous recommandons de lire d'abord 🔐 Contrôle d’accès basé sur les rôles (RBAC) pour comprendre les concepts de base de Logto RBAC et comment configurer correctement les ressources API.
Configurer le client Logto
Une fois que vous avez configuré les ressources API, vous pouvez les ajouter lors de la configuration de Logto dans votre application :
import LogtoClient from '@logto/browser';
const logtoClient = new LogtoClient({
// ...other configs
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // Ajouter des ressources API
});
Chaque ressource API a ses propres permissions (portées).
Par exemple, la ressource https://shopping.your-app.com/api a les permissions shopping:read et shopping:write, et la ressource https://store.your-app.com/api a les permissions store:read et store:write.
Pour demander ces permissions, vous pouvez les ajouter lors de la configuration de Logto dans votre application :
import LogtoClient from '@logto/browser';
const logtoClient = new LogtoClient({
// ...other configs
portées: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
ressources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'], // Ajouter des ressources API
});
Vous pouvez remarquer que les portées sont définies séparément des ressources API. Cela est dû au fait que les Indicateurs de ressource pour OAuth 2.0 spécifient que les portées finales pour la requête seront le produit cartésien de toutes les portées de tous les services cibles.
Ainsi, dans le cas ci-dessus, les portées peuvent être simplifiées à partir de la définition dans Logto, les deux ressources API peuvent avoir les portées read et write sans le préfixe. Ensuite, dans la configuration de Logto :
import LogtoClient, { UserScope } from '@logto/browser';
const logtoClient = new LogtoClient({
// ...other configs
scopes: ['read', 'write'],
resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
});
Pour chaque ressource API, il demandera à la fois les portées read et write.
Il est acceptable de demander des portées qui ne sont pas définies dans les ressources API. Par exemple, vous pouvez demander la portée email même si les ressources API n'ont pas la portée email disponible. Les portées non disponibles seront ignorées en toute sécurité.
Après une connexion réussie, Logto émettra les portées appropriées aux ressources API en fonction des rôles de l'utilisateur.
Récupérer le jeton d’accès pour la ressource API
Pour récupérer le jeton d’accès pour une ressource API spécifique, vous pouvez utiliser la méthode getAccessToken :
const accessToken = await logtoClient.getAccessToken('https://store.your-app.com/api');
console.log('Jeton d’accès', accessToken);
Cette méthode renverra un jeton d’accès JWT qui peut être utilisé pour accéder à la ressource API lorsque l’utilisateur a les Permissions associées. Si le jeton d’accès mis en cache actuel a expiré, cette méthode essaiera automatiquement d’utiliser un jeton de rafraîchissement pour obtenir un nouveau jeton d’accès.
Récupérer les jetons d’organisation
Si l'Organisation est nouvelle pour vous, veuillez lire 🏢 Organisations (Multi-tenancy) pour commencer.
Vous devez ajouter la portée UserScope.Organizations lors de la configuration du client Logto :
import LogtoClient, { UserScope } from '@logto/browser';
const logtoClient = new LogtoClient({
// ...other configs
scopes: [UserScope.Organisations],
});
Une fois l'utilisateur connecté, vous pouvez récupérer le jeton d’organisation pour l'utilisateur :
// Obtenez les organizationIds à partir des userInfo
const claims = await logtoClient.getIdTokenClaims();
const organizationIds = claims.organizations;
/**
* Ou à partir des revendications du jeton d’identifiant
*
* const claims = await logtoClient.getIdTokenClaims();
* const organizationIds = claims.organizations;
*/
// Obtenez le jeton d’accès de l’organisation
if (organizationIds.length > 0) {
const organizationId = organizationIds[0];
const organizationAccessToken = await logtoClient.getOrganizationToken(organizationId);
console.log('Jeton d’accès de l’organisation', organizationAccessToken);
}
./code/_scopes-and-claims-code.mdx./code/_config-organization-code.mdx
Attacher le jeton d’accès aux en-têtes de requête
Placez le jeton dans le champ Authorization des en-têtes HTTP avec le format Bearer (Bearer YOUR_TOKEN), et vous êtes prêt à partir.
Le flux d'intégration du jeton Bearer peut varier en fonction du framework ou du demandeur que vous utilisez. Choisissez votre propre méthode pour appliquer l'en-tête de requête Authorization.