Ajoutez l’authentification à votre application Angular

astuce

• La démonstration suivante est construite sur Angular 18.0.0 et angular-auth-oidc-client.
• Le projet d'exemple est disponible dans le répertoire GitHub.

Prérequis

• Un compte Logto Cloud ou un Logto auto-hébergé.
• Une application monopage Logto créée.

Installation

Installez Logto JS core SDK et la bibliothèque cliente Angular OIDC :

npm

npm i @logto/js angular-auth-oidc-client

pnpm

pnpm add @logto/js angular-auth-oidc-client

yarn

yarn add @logto/js angular-auth-oidc-client

Intégration

Configurer l'application

Dans votre projet Angular, ajoutez le fournisseur d'authentification dans votre app.config.ts :

app/app.config.ts

import { buildAngularAuthConfig } from '@logto/js';
import { provideAuth } from 'angular-auth-oidc-client';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        endpoint: '<your-logto-endpoint>',
        appId: '<your-app-id>',
        redirectUri: 'http://localhost:3000/callback',
        postLogoutRedirectUri: 'http://localhost:3000/',
      }),
    }),
    // ...other providers
  ],
};

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 :

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

Puisque nous utilisons http://localhost:3000/callback comme URI de redirection, nous devons maintenant la gérer correctement. La bibliothèque angular-auth-oidc-client fournit un support intégré pour gérer la redirection. Vous pouvez simplement configurer correctement les configurations du fournisseur d'authentification et la bibliothèque s'occupera du reste.

app/app.config.ts

export const appConfig: ApplicationConfig = {
  providers: [
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other config
        redirectUri: 'http://localhost:3000/callback',
        postLogoutRedirectUri: 'http://localhost:3000/',
      }),
    }),
    // ...other providers
  ],
};

Implémenter la connexion et la déconnexion

Dans le composant où vous souhaitez implémenter la connexion et la déconnexion (par exemple, app.component.ts), injectez le OidcSecurityService et utilisez-le pour vous connecter et vous déconnecter.

app/app.component.ts

import { OidcSecurityService } from 'angular-auth-oidc-client';

export class AppComponent implements OnInit {
  constructor(public oidcSecurityService: OidcSecurityService) {}

  signIn() {
    this.oidcSecurityService.authorize();
  }

  signOut() {
    this.oidcSecurityService.logoff().subscribe((result) => {
      console.log('app sign-out', result);
    });
  }
}

Ensuite, dans le modèle, ajoutez des boutons pour se connecter et se déconnecter :

app/app.component.html

<button (click)="signIn()">Se connecter</button>
<br />
<button (click)="signOut()">Se déconnecter</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 :

1. Exécutez votre application, vous verrez le bouton de connexion.
2. Cliquez sur le bouton de connexion, le SDK initiera le processus de connexion et vous redirigera vers la page de connexion Logto.
3. Après vous être connecté, vous serez redirigé vers votre application et verrez le bouton de déconnexion.
4. Cliquez sur le bouton de déconnexion pour effacer le stockage local et vous déconnecter.

Obtenir des informations sur l'utilisateur

Une fois que l'utilisateur s'est connecté avec succès, Logto émettra un jeton d’identifiant (ID token) qui contient les revendications d'informations utilisateur. Le jeton d’identifiant est un JSON Web Token (JWT).

Il est important de noter que les revendications d'informations utilisateur qui peuvent être récupérées dépendent des portées utilisées par l'utilisateur lors de la connexion, et en considérant les performances et la taille des données, le jeton d’identifiant peut ne pas contenir toutes les revendications utilisateur, certaines revendications utilisateur ne sont disponibles que dans le point de terminaison userinfo (voir la liste ci-dessous).

L'utilitaire buildAngularAuthConfig() activera autoUserInfo et renewUserInfoAfterTokenRenew s'il n'y a pas de resource fourni dans la configuration. Cela signifie que Logto récupérera automatiquement les informations utilisateur après la connexion de l'utilisateur et renouvellera les informations utilisateur après le renouvellement du jeton.

info

Pour en savoir plus sur la configuration de la bibliothèque angular-auth-oidc-client, consultez la documentation officielle.

Afficher les informations utilisateur

Le OidcSecurityService fournit un moyen pratique de s'abonner à l'état d'authentification ainsi qu'aux informations utilisateur :

app/app.component.ts

import { OidcSecurityService } from 'angular-auth-oidc-client';
import { decodeIdToken, type IdTokenClaims } from '@logto/js';

export class AppComponent implements OnInit {
  isAuthenticated = false;
  idTokenClaims?: IdTokenClaims;
  accessToken?: string;

  constructor(public oidcSecurityService: OidcSecurityService) {}

  ngOnInit() {
    this.oidcSecurityService.checkAuth().subscribe(({ isAuthenticated, idToken, accessToken }) => {
      console.log('app authenticated', isAuthenticated, idToken);
      this.isAuthenticated = isAuthenticated;
      this.idTokenClaims = decodeIdToken(idToken);
      this.accessToken = accessToken;
    });
  }

  // ...other methods
}

Et utilisez-le dans le modèle :

app/app.component.html

<button *ngIf="!isAuthenticated" (click)="signIn()">Sign in</button>
<ng-container *ngIf="isAuthenticated">
  <pre>{{ idTokenClaims | json }}</pre>
  <p>Access token: {{ accessToken }}</p>
  <!-- ... -->
  <button (click)="signOut()">Sign out</button>
</ng-container>

Demander des revendications supplémentaires

Il se peut que certaines informations utilisateur soient manquantes dans l'objet retourné par idToken. 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.

info

Une "revendication" est une assertion 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 :

astuce

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 du fournisseur d'authentification :

app/app.config.ts

import { UserScope, buildAngularAuthConfig } from '@logto/js';

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other configs
        scopes: [
          UserScope.Email,
          UserScope.Phone,
          UserScope.CustomData,
          UserScope.Identities,
          UserScope.Organizations,
        ],
      }),
    }),
    // ...other providers
  ],
};

Ensuite, vous pouvez accéder aux revendications supplémentaires dans la valeur de retour de idToken.

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 configurer l'option userData :

app/app.component.ts

import { OidcSecurityService } from 'angular-auth-oidc-client';
import { type UserInfoResponse } from '@logto/js';

export class AppComponent implements OnInit {
isAuthenticated = false;
userData?: UserInfoResponse;
accessToken?: string;

constructor(public oidcSecurityService: OidcSecurityService) {}

ngOnInit() {
  this.oidcSecurityService
    .checkAuth()
    .subscribe(({ isAuthenticated, userData, accessToken }) => {
      console.log('app authenticated', isAuthenticated, idToken);
      this.isAuthenticated = isAuthenticated;
      this.userData = userData;
      this.accessToken = accessToken;
    });
}

// ...other methods
}

// Now you can access the claim `userData.custom_data`

En configurant userData, le SDK récupérera les informations de l'utilisateur en faisant une requête à l' point de terminaison userinfo après que l'utilisateur se soit connecté, et userData sera disponible une fois la requête terminée.

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

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.

Ressources API

Configurer angular-auth-oidc-client pour la ressource 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.

Une fois que vous avez configuré les ressources API, vous pouvez les ajouter lors de la configuration de Logto dans votre application :

/app/app.config.ts

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other config
        resource: 'https://your-api-resource.com',
      }),
    }),
    // ...other providers
  ],
};

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 :

app/app.config.ts

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(withFetch()),
    provideAuth({
      config: buildAngularAuthConfig({
        // ...other config
        resource: 'https://your-api-resource.com',
        scopes: ['openid', 'profile', 'offline_access', 'read', 'write'],
      }),
    }),
    // ...other providers
  ],
};

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.

remarque

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.

Maintenant, le jeton d’accès (Access token) sera au format JSON Web Token (JWT) au lieu d'une chaîne aléatoire (jeton opaque).

attention

Les deux autoUserInfo et renewUserInfoAfterTokenRenew seront désactivés lorsque resource est défini. Cela est dû au fait que le jeton d’accès (Access token) sera demandé pour la ressource API spécifique et non pour le point de terminaison des informations utilisateur.

Actuellement, seuls les SDK officiels de Logto prennent en charge la capacité de demander à la fois des informations utilisateur et des jetons d’accès (Access tokens) pour les ressources API. Si vous avez besoin de demander les deux, n'hésitez pas à nous contacter.

Lectures complémentaires

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