Ajoutez l’authentification à votre application Expo (React Native)

astuce:

La démonstration suivante est construite sur Expo ~50.0.6.
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 native Logto créée.

Installation

Installez Logto SDK et les dépendances homologues via votre gestionnaire de paquets préféré :

npm
Yarn
pnpm

npm i @logto/rn
npm i expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage

yarn add @logto/rn
yarn add expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage

pnpm add @logto/rn
pnpm add expo-crypto expo-secure-store expo-web-browser @react-native-async-storage/async-storage

Le package @logto/rn est le SDK pour Logto. Les autres packages sont ses dépendances homologues. Ils ne peuvent pas être listés comme dépendances directes car le CLI Expo exige que toutes les dépendances pour les modules natifs soient installées directement dans le package.json du projet racine.

remarque:

Si vous installez ceci dans une application React Native bare, vous devriez également suivre ces instructions d'installation supplémentaires.

Intégration

Initialiser le fournisseur Logto

Importez et utilisez LogtoProvider pour fournir un contexte Logto :

App.tsx
import { LogtoProvider, LogtoConfig } from '@logto/rn';

const config: LogtoConfig = {
  endpoint: '<your-logto-endpoint>',
  appId: '<your-application-id>',
};

const App = () => (
  <LogtoProvider config={config}>
    <YourAppContent />
  </LogtoProvider>
);

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.

Passez à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection native (par exemple, io.logto://callback), puis cliquez sur "Enregistrer".

Pour iOS, le schéma de l'URI de redirection n'a pas vraiment d'importance puisque la classe ASWebAuthenticationSession écoutera l'URI de redirection, qu'elle soit enregistrée ou non.
Pour Android, le schéma de l'URI de redirection doit être renseigné dans le fichier app.json d'Expo, par exemple :
app.json
```
{
  "expo": {
    "scheme": "io.logto"
  }
}
```

Revenez maintenant à votre application, vous pouvez utiliser le hook useLogto pour vous connecter et vous déconnecter :

App.tsx
import { useLogto } from '@logto/rn';
import { Button } from 'react-native';

const Content = () => {
  const { signIn, signOut, isAuthenticated } = useLogto();

  return (
    <div>
      {isAuthenticated ? (
        <Button title="Se déconnecter" onPress={async () => signOut()} />
      ) : (
        // Remplacez l'URI de redirection par la vôtre
        <Button title="Se connecter" onPress={async () => signIn('io.logto://callback')} />
      )}
    </div>
  );
};

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.

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

App.tsx
import { useLogto } from '@logto/rn';
import { Button, Text } from 'react-native';

const Content = () => {
  const { getIdTokenClaims, isAuthenticated } = useLogto();
  const [user, setUser] = useState(null);

  useEffect(() => {
    if (isAuthenticated) {
      getIdTokenClaims().then((claims) => {
        setUser(claims);
      });
    }
  }, [isAuthenticated]);

  return (
    <div>
      {isAuthenticated ? (
        <>
          <Text>{user?.name}</Text>
          <Text>{user?.email}</Text>
          <Button title="Sign out" onPress={async () => signOut()} />
        </>
      ) : (
        <Button title="Sign in" onPress={async () => signIn('io.logto://callback')} />
      )}
    </div>
  );
};

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.

Pour demander des Portées supplémentaires, vous pouvez passer les Portées à l'objet LogtoConfig :

App.tsx
import { LogtoProvider, LogtoConfig, UserScope } from '@logto/rn';

const config: LogtoConfig = {
  appId: '<your-application-id>',
  endpoint: '<your-logto-endpoint>',
  scopes: [
    UserScope.Email,
    UserScope.Phone,
    UserScope.CustomData,
    UserScope.Identities,
    UserScope.Organizations,
  ],
};

const App = () => (
  <LogtoProvider config={config}>{/* Votre contenu d'application */}</LogtoProvider>
);

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.tsx
import { useLogto } from '@logto/rn';
import { Button, Text } from 'react-native';

const Content = () => {
  const { fetchUserInfo, isAuthenticated } = useLogto();
  const [user, setUser] = useState(null);

  useEffect(() => {
    if (isAuthenticated) {
      fetchUserInfo().then((userInfo) => {
        setUser(userInfo);
      });
    }
  }, [isAuthenticated]);

  return (
    <div>
      {isAuthenticated ? (
        <>
          <Text>{user?.name}</Text>
          <Text>{user?.email}</Text>
          <Button title="Se déconnecter" onPress={async () => signOut()} />
        </>
      ) : (
        <Button title="Se connecter" onPress={async () => signIn('io.logto://callback')} />
      )}
    </div>
  );
};

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.

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

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.tsx
import { LogtoConfig } from '@logto/rn';

const config: LogtoConfig = {
  appId: '<your-application-id>',
  endpoint: '<your-logto-endpoint>',
  // Ajouter des ressources API
  resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/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 :

App.tsx
import { LogtoConfig } from '@logto/rn';

const config: LogtoConfig = {
  appId: '<your-application-id>',
  endpoint: '<your-logto-endpoint>',
  scopes: ['shopping:read', 'shopping:write', 'store:read', 'store:write'],
  resources: ['https://shopping.your-app.com/api', 'https://store.your-app.com/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 :

App.tsx
import { LogtoConfig } from '@logto/rn';

const config: LogtoConfig = {
  appId: '<your-application-id>',
  endpoint: '<your-logto-endpoint>',
  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.

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.

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 :

AccessToken.tsx
import { useLogto } from '@logto/rn';

const AccessToken = () => {
  const { isAuthenticated, getAccessToken } = useLogto();
  const [accessToken, setAccessToken] = useState('');

  useEffect(() => {
    (async () => {
      if (isAuthenticated) {
        const token = await getAccessToken('https://shopping.your-app.com/api');
        setAccessToken(token);
      }
    })();
  }, [isAuthenticated, getAccessToken]);

  return <p>{{ accessToken }}</p>;
};

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 le jeton d’organisation pour l’utilisateur

Si l'Organisation est nouvelle pour vous, veuillez lire 🏢 Organisations (Multi-tenancy) pour commencer.

Vous devez ajouter la portée UserScope.Organisations lors de la configuration du client Logto :

App.tsx
import { LogtoConfig, UserScope } from '@logto/rn';

const config: LogtoConfig = {
  // ...other configs
  scopes: [UserScope.Organisations],
};

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

Organizations.tsx
import { useLogto } from '@logto/rn';
import { useEffect, useState } from 'react';

const Organizations = () => {
  const { isAuthenticated, getOrganizationToken, getIdTokenClaims } = useLogto();
  const [organizationIds, setOrganizationIds] = useState<string[]>();

  useEffect(() => {
    (async () => {
      if (!isAuthenticated) {
        return;
      }
      const claims = await getIdTokenClaims();

      console.log('Revendications de jeton d’identifiant', claims);
      setOrganizationIds(claims?.organizations);
    })();
  }, [isAuthenticated, getIdTokenClaims]);

  return (
    <section>
      <ul>
        {organizationIds?.map((organizationId) => {
          return (
            <li key={organizationId}>
              <span>{organizationId}</span>
              <button
                type="button"
                onClick={async () => {
                  console.log('jeton brut', await getOrganizationToken(organizationId));
                }}
              >
                récupérer le jeton (voir la console)
              </button>
            </li>
          );
        })}
      </ul>
    </section>
  );
};

export default Organizations;

Dépannage

Impossible de résoudre `@logto/client/shim`

remarque:

Pour les utilisateurs utilisant la version SDK <= v0.3.0, veuillez suivre les instructions ci-dessous pour résoudre le problème.
Pour les utilisateurs utilisant la version SDK >= v0.4.0, veuillez ignorer cette section. Ce problème a été corrigé dans la dernière version.

Pour les projets Expo, si vous rencontrez l'erreur Unable to resolve "@logto/client/shim" from "node_modules/@logto/rn/lib/index.js", vous pouvez la résoudre en ajoutant ce qui suit à votre fichier metro.config.js :

metro.config.js
const config = {
  // ...
  resolver: {
    unstable_enablePackageExports: true,
  },
};

module.exports = config;

Cette erreur indique que le package @logto/rn n'est pas capable de résoudre le module @logto/client/shim.

Comme les exports de nœuds ont été utilisés dans le package @logto/client, et que les exports de package ne sont pas activés par défaut dans le bundler Metro, vous devez les activer manuellement.

Voir le support des exports de package React Native pour plus de détails.

Lectures complémentaires

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​

Implémenter la connexion et la déconnexion​

Concernant la connexion basée sur la redirection​

Point de contrôle : Testez votre application​

Obtenez des informations sur l'utilisateur​

Afficher les informations de l'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 et organisations​

Configurer le client Logto​

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

Récupérer le jeton d’organisation pour l’utilisateur​

Dépannage​

Impossible de résoudre @logto/client/shim​

Lectures complémentaires​

Prérequis

Installation

Intégration

Initialiser le fournisseur Logto

Implémenter la connexion et la déconnexion

Concernant la connexion basée sur la redirection

Point de contrôle : Testez votre application

Obtenez des informations sur l'utilisateur

Afficher les informations de l'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 et organisations

Configurer le client Logto

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

Récupérer le jeton d’organisation pour l’utilisateur

Dépannage

Impossible de résoudre `@logto/client/shim`

Lectures complémentaires