Ajoutez l’authentification à votre application Angular (Add authentication to your Angular application)

Ce guide vous montrera comment intégrer le SDK Logto Angular v2 dans votre application.

astuce:

Ce guide utilise le SDK officiel @logto/angular v2, qui prend en charge Angular 20 et fournit l'injection de dépendances ainsi que les Signals.
Le projet d'exemple est disponible dans notre dépôt SDK.

Prérequis

Un compte Logto Cloud ou un Logto auto-hébergé.
Une application monopage (SPA) créée dans la Console Logto.
Un projet Angular 20.

Installation

Installez le SDK Logto via votre gestionnaire de paquets préféré :

npm
pnpm
yarn

npm i @logto/angular

pnpm add @logto/angular

yarn add @logto/angular

Intégration

Initialiser le fournisseur Logto

Dans votre projet Angular, enregistrez provideLogto et vos routes d'application dans app.config.ts :

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideLogto } from '@logto/angular';

import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
    }),
    provideRouter(routes),
    // ...autres providers
  ],
};

provideLogto restaure automatiquement l'état d'authentification après le premier rendu du navigateur. Vous n'avez pas besoin d'appeler une méthode d'initialisation dans vos composants.

remarque:

Lorsque vous utilisez le rendu côté serveur (SSR), l'état d'authentification et les jetons sont disponibles uniquement dans le navigateur. Utilisez isLoading() pour afficher un état de chargement jusqu'à la fin de l'initialisation. Si vous avez besoin de données authentifiées lors du rendu serveur, utilisez un SDK serveur ou BFF.

Configurer les URI 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).

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.

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

Créez un composant de rappel pour terminer la connexion après que Logto ait redirigé l'utilisateur vers votre application. Utilisez afterNextRender pour que le traitement du callback ne s'exécute que dans le navigateur :

app/callback.component.ts
import { afterNextRender, Component, inject } from '@angular/core';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-callback',
  standalone: true,
  template: `
    @if (logto.error(); as error) {
      <p role="alert">{{ error.message }}</p>
    } @else {
      <p>Finalisation de la connexion...</p>
    }
  `,
})
export class CallbackComponent {
  readonly logto = inject(LogtoService);

  constructor() {
    afterNextRender(() => {
      void (async () => {
        const callbackUri = window.location.href;

        if (!(await this.logto.isSignInRedirected(callbackUri))) {
          window.location.replace(window.location.origin);
          return;
        }

        await this.logto.handleSignInCallback(callbackUri);
      })().catch(() => {
        // Le SDK expose les erreurs de callback via logto.error() pour le template.
      });
    });
  }
}

isSignInRedirected() vérifie si l'URL correspond à une session de connexion active. Si quelqu'un visite la route de callback sans session, cet exemple le renvoie à la page d'accueil de l'application au lieu de tenter de finaliser la connexion.

Enregistrez la route de callback dans app.routes.ts. Elle doit correspondre au chemin de votre URI de redirection et ne doit pas nécessiter d'authentification. Par exemple, utilisez callback pour une URI de redirection se terminant par /callback :

app/app.routes.ts
import { type Routes } from '@angular/router';

import { CallbackComponent } from './callback.component';

export const routes: Routes = [
  { path: 'callback', component: CallbackComponent },
  // ...autres routes
];

Le composant racine doit contenir un <router-outlet /> pour afficher cette route, comme montré à l'étape suivante.

Injectez LogtoService pour démarrer la connexion et la déconnexion. Passez les URI de redirection enregistrées à ces méthodes. Le postRedirectUri indique au SDK où naviguer après avoir traité avec succès le callback de connexion :

remarque:

Avant d'appeler signIn(), assurez-vous d'avoir correctement configuré l'URI de redirection dans la console d'administration.

app/app.component.ts
import { Component, inject } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [RouterOutlet],
  templateUrl: './app.component.html',
})
export class AppComponent {
  readonly logto = inject(LogtoService);

  async signIn() {
    await this.logto.signIn({
      redirectUri: 'http://localhost:3000/callback',
      postRedirectUri: window.location.origin,
    });
  }

  async signOut() {
    await this.logto.signOut('http://localhost:3000/');
  }
}

Lisez les signaux isLoading(), isAuthenticated() et error() directement dans le template :

app/app.component.html
@if (logto.error(); as error) {
<p role="alert">{{ error.message }}</p>
} @if (logto.isLoading()) {
<p>Chargement…</p>
} @else if (logto.isAuthenticated()) {
<button type="button" (click)="signOut()">Déconnexion</button>
} @else {
<button type="button" (click)="signIn()">Connexion</button>
}

<router-outlet />

Gardez <router-outlet /> en dehors des conditions d'authentification afin que le callback puisse s'afficher avant que l'utilisateur ne soit connecté.

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 le bouton de déconnexion.
Cliquez sur le bouton de déconnexion pour effacer le stockage des jetons et vous déconnecter.

Obtenir les informations de l’utilisateur

Afficher les informations utilisateur

Pour afficher les informations de l'utilisateur, utilisez getIdTokenClaims() pour lire les revendications (Claims) du jeton d’identifiant (ID token) sans requête réseau supplémentaire. Ajoutez un effect à votre AppComponent pour charger les revendications lorsque isAuthenticated() devient vrai, y compris lors de la restauration d'une session existante. Importez JsonPipe pour afficher le résultat :

app/app.component.ts
import { JsonPipe } from '@angular/common';
import { Component, effect, inject, signal } from '@angular/core';
import { RouterOutlet } from '@angular/router';
import { LogtoService, type IdTokenClaims } from '@logto/angular';

@Component({
  selector: 'app-root',
  standalone: true,
  imports: [JsonPipe, RouterOutlet],
  templateUrl: './app.component.html',
})
export class AppComponent {
  readonly logto = inject(LogtoService);
  readonly user = signal<IdTokenClaims | undefined>(undefined);

  constructor() {
    effect(() => {
      if (!this.logto.isAuthenticated()) {
        this.user.set(undefined);
        return;
      }

      void this.logto
        .getIdTokenClaims()
        .then((claims) => {
          this.user.set(claims);
        })
        .catch(() => {
          // Le SDK expose l’erreur via logto.error() pour le template.
        });
    });
  }

  // ...conservez les méthodes signIn() et signOut() de l’étape précédente
}

Ajoutez ce qui suit à l'intérieur de la branche logto.isAuthenticated() de votre template :

app/app.component.html
@if (user(); as claims) {
<pre>{{ claims | json }}</pre>
}

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.

info:

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 :

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.

Ajoutez les portées (scopes) à votre configuration provideLogto :

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto, UserScope } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: [
        UserScope.Email,
        UserScope.Phone,
        UserScope.CustomData,
        UserScope.Identities,
        UserScope.Organizations,
      ],
    }),
    // ...autres providers
  ],
};

Reconnectez-vous après avoir modifié les portées. Les revendications supplémentaires du jeton d’identifiant (ID token), telles que email et phone_number, seront disponibles via getIdTokenClaims() et affichées par l’exemple ci-dessus.

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 fetchUserInfo() :

app/app.component.ts
// Ajoutez cette méthode à AppComponent et appelez-la après la connexion.
async loadUserInfo() {
const userInfo = await this.logto.fetchUserInfo();
// Vous pouvez maintenant accéder à userInfo.custom_data, userInfo.identities, etc.
return userInfo;
}

Cette méthode récupérera les informations de l'utilisateur en faisant une requête à l' point de terminaison userinfo. Pour en savoir plus sur les portées et revendications disponibles, consultez la section Portées et revendications.

fetchUserInfo() peut être utilisé en parallèle des jetons d’accès (Access tokens) de ressource API. La configuration de resources n'empêche pas le SDK de demander les informations utilisateur.

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.

remarque:

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
email	`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.

info:

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

remarque:

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 :

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    }),
    // ...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
import { type ApplicationConfig } from '@angular/core';
import { provideLogto } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
      resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    }),
    // ...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.

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 :

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: ['read', 'write'],
      resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/api'],
    }),
    // ...other providers
  ],
};

Pour chaque ressource API, il demandera à la fois les portées read et write.

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.

Reconnectez-vous après avoir modifié les ressources ou les portées afin que l'utilisateur puisse autoriser la configuration mise à jour.

Récupérer un 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() :

app/api-resource.component.ts
import { Component, inject, signal } from '@angular/core';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-api-resource',
  standalone: true,
  template: `
    @if (logto.error(); as error) {
      <p role="alert">{{ error.message }}</p>
    }
    @if (logto.isAuthenticated()) {
      <button type="button" [disabled]="logto.isLoading()" (click)="loadAccessToken()">
        Obtenir un jeton d’accès à l’API (Get API access token)
      </button>
      <pre>{{ accessToken() }}</pre>
    }
  `,
})
export class ApiResourceComponent {
  readonly logto = inject(LogtoService);
  readonly accessToken = signal('');

  async loadAccessToken() {
    this.accessToken.set(await this.logto.getAccessToken('https://shopping.your-app.com/api'));
  }
}

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.

Utilisez l'identifiant exact de la ressource de votre configuration. Appelez getAccessToken(resource) chaque fois que vous effectuez une requête API afin que le SDK puisse retourner un jeton valide, plutôt que de conserver indéfiniment un jeton dans votre composant.

Récupérer des 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 :

app/app.config.ts
import { type ApplicationConfig } from '@angular/core';
import { provideLogto, UserScope } from '@logto/angular';

export const appConfig: ApplicationConfig = {
  providers: [
    provideLogto({
      endpoint: '<your-logto-endpoint>',
      appId: '<your-app-id>',
      scopes: [UserScope.Organizations],
    }),
    // ...other providers
  ],
};

Une fois l'utilisateur connecté, vous pouvez récupérer le jeton d’organisation pour l'utilisateur :

app/organizations.component.ts
import { Component, effect, inject, signal } from '@angular/core';
import { LogtoService } from '@logto/angular';

@Component({
  selector: 'app-organizations',
  standalone: true,
  template: `
    @if (logto.error(); as error) {
      <p role="alert">{{ error.message }}</p>
    }
    @if (logto.isAuthenticated()) {
      <ul>
        @for (organizationId of organizationIds(); track organizationId) {
          <li>
            <span>{{ organizationId }}</span>
            <button
              type="button"
              [disabled]="logto.isLoading()"
              (click)="loadOrganizationToken(organizationId)"
            >
              Obtenir le jeton d’organisation (Get organization token)
            </button>
          </li>
        }
      </ul>
      <pre>{{ organizationToken() }}</pre>
    }
  `,
})
export class OrganizationsComponent {
  readonly logto = inject(LogtoService);
  readonly organizationIds = signal<string[]>([]);
  readonly organizationToken = signal('');

  constructor() {
    effect(() => {
      if (!this.logto.isAuthenticated()) {
        this.organizationIds.set([]);
        this.organizationToken.set('');
        return;
      }

      void this.logto
        .getIdTokenClaims()
        .then((claims) => {
          this.organizationIds.set(claims.organizations ?? []);
        })
        .catch(() => {
          // Le SDK expose l’erreur via logto.error() pour le template.
        });
    });
  }

  async loadOrganizationToken(organizationId: string) {
    this.organizationToken.set(await this.logto.getOrganizationToken(organizationId));
  }
}

Fusionnez UserScope.Organizations avec toute portée existante, puis reconnectez-vous après avoir mis à jour la configuration. getOrganizationToken(organizationId) retourne un jeton pour l’organisation Logto sélectionnée ; utilisez getAccessToken(resource) pour un jeton de ressource API.

Attacher le jeton d’accès aux en-têtes de requête

Placez le jeton dans l’en-tête HTTP Authorization en utilisant le format Bearer (Bearer YOUR_TOKEN). Par exemple, ajoutez cette méthode à un composant authentifié qui injecte LogtoService :

async fetchProducts() {
  const accessToken = await this.logto.getAccessToken('https://shopping.your-app.com/api');
  const response = await fetch('https://shopping.your-app.com/api/products', {
    headers: {
      Authorization: `Bearer ${accessToken}`,
    },
  });

  if (!response.ok) {
    throw new Error(`Request failed: ${response.status}`);
  }

  return response.json();
}

remarque:

L’exemple utilise fetch. Si vous utilisez Angular HttpClient, définissez le même en-tête Authorization dans les options de la requête.

Pour aller plus loin

Parcours utilisateur final : flux d’authentification, flux de compte et flux d’organisation Configurer les connecteurs Autorisation (Authorization)

Prérequis​

Installation​

Intégration​

Initialiser le fournisseur Logto​

Configurer les URI de redirection​

Concernant la connexion basée sur la redirection​

Configurer les URIs de redirection​

Gérer la redirection​

Implémenter la connexion et la déconnexion​

Point de contrôle : Testez votre application​

Obtenir les informations de l’utilisateur​

Afficher les informations utilisateur​

Demander des revendications supplémentaires​

Revendications nécessitant des requêtes réseau​

Portées et revendications​

Portées OIDC standard​

Portées étendues​

Ressources API​

Configurer le client Logto​

Récupérer un jeton d’accès pour la ressource API​

Récupérer des jetons d’organisation​

Attacher le jeton d’accès aux en-têtes de requête​

Pour aller plus loin​

Prérequis

Installation

Intégration

Initialiser le fournisseur Logto

Configurer les URI de redirection

Concernant la connexion basée sur la redirection

Configurer les URIs de redirection

Gérer la redirection

Implémenter la connexion et la déconnexion

Point de contrôle : Testez votre application

Obtenir les informations de l’utilisateur

Afficher les informations utilisateur

Demander des revendications supplémentaires

Revendications nécessitant des requêtes réseau

Portées et revendications

Portées OIDC standard

Portées étendues

Ressources API

Configurer le client Logto

Récupérer un jeton d’accès pour la ressource API

Récupérer des jetons d’organisation

Attacher le jeton d’accès aux en-têtes de requête

Pour aller plus loin