Ajoutez l’authentification à votre application iOS (Swift)

remarque:

Ce guide suppose que vous avez créé une Application de type "Native app" dans la Console d'administration.

Installation

remarque:

La version minimale d’iOS prise en charge par Logto Swift SDK est iOS 13.

Le SDK Logto Swift existe en deux versions majeures :

v2 : Ouvre l’expérience de connexion dans ASWebAuthenticationSession (le navigateur système), ce qui permet la connexion par passkey et partage la session du navigateur. Notez que la v2 supprime les cibles de plugins sociaux natifs ; les connecteurs sociaux fonctionnent toujours via le navigateur. Si vous dépendez du transfert natif du SDK WeChat ou Alipay, restez en v1.
v1 : Ouvre l’expérience de connexion dans une WebView intégrée, ce qui est requis par les cibles de plugins sociaux natifs, mais ne prend pas en charge la connexion par passkey (WebView ne prend pas en charge WebAuthn, la norme sous-jacente des passkeys).

Ce guide couvre les deux versions. Choisissez votre version dans les onglets ci-dessous, et ce choix sera synchronisé tout au long de ce guide.

Utilisez l’URL suivante pour ajouter le SDK Logto comme dépendance dans Swift Package Manager.

https://github.com/logto-io/swift.git

Depuis Xcode 11, vous pouvez importer directement un package Swift sans outil supplémentaire.

Lorsque Xcode demande la version du package, choisissez la version que vous souhaitez intégrer :

Utilisez la dernière version v2 comme version. La dernière version v2 est 2.0.0.

Si vous utilisez directement Package.swift :

Package.swift
.package(url: "https://github.com/logto-io/swift.git", from: "2.0.0")

Utilisez la dernière version v1 si vous avez besoin des cibles de plugins sociaux natifs. La dernière version v1 est 1.2.0.

Si vous utilisez directement Package.swift :

Package.swift
.package(url: "https://github.com/logto-io/swift.git", from: "1.2.0")

Nous ne prenons pas en charge Carthage et CocoaPods pour le moment en raison de certains problèmes techniques.

Carthage

Carthage nécessite un fichier xcodeproj pour compiler. Nous essaierons de trouver une solution de contournement plus tard.

CocoaPods

CocoaPods ne prend pas en charge les dépendances locales et les monorepos, il est donc difficile de créer un .podspec pour ce dépôt.

Intégration

Init `LogtoClient`

Initialisez le client en créant une instance LogtoClient avec un objet LogtoConfig.

ContentView.swift
import Logto
import LogtoClient

let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // Par exemple, http://localhost:3001
  appId: "<your-app-id>"
)
let client = LogtoClient(useConfig: config)

info:

Par défaut, nous stockons les informations d'identification comme le Jeton d’identifiant (ID token) et le Jeton de rafraîchissement (Refresh token) dans le Trousseau. Ainsi, l'utilisateur n'a pas besoin de se reconnecter lorsqu'il revient.

Pour désactiver ce comportement, définissez usingPersistStorage sur false :

let config = try? LogtoConfig(
  // ...
  usingPersistStorage: false
)

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.

Configurer l’URI de redirection

Passons à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection io.logto.app://callback et cliquez sur "Enregistrer les modifications".

En v2, l’expérience de connexion s’ouvre dans ASWebAuthenticationSession (le navigateur système), et la redirection est renvoyée vers votre application via la correspondance de callback au niveau du système d’exploitation. Pour une URI de redirection avec un schéma personnalisé comme io.logto.app://callback, enregistrez uniquement la partie schéma (io.logto.app) dans le Info.plist de votre application, puis ajoutez l’URI de redirection complète dans les URI de redirection de votre application Logto.

Dans Xcode, ouvrez la cible de votre application, sélectionnez Info, développez URL Types, et ajoutez une entrée avec io.logto.app dans URL Schemes. Si vous modifiez directement le Info.plist, ajoutez :

Info.plist
<key>CFBundleURLTypes</key>
<array>
  <dict>
    <key>CFBundleTypeRole</key>
    <string>Editor</string>
    <key>CFBundleURLName</key>
    <string>io.logto.app</string>
    <key>CFBundleURLSchemes</key>
    <array>
      <string>io.logto.app</string>
    </array>
  </dict>
</array>

Pour le flux navigateur en v2, il n’est pas nécessaire d’appeler LogtoClient.handle(url:) ; cette API de transfert de plugin a été supprimée avec le flux WebView intégré.

Utiliser Universal Links au lieu d’un schéma personnalisé ?

Vous pouvez également utiliser une URI de redirection HTTPS telle que https://example.com/callback :

Ajoutez la capacité Associated Domains à votre application.
Configurez webcredentials:example.com pour que ASWebAuthenticationSession puisse faire correspondre les callbacks HTTPS sur iOS 17.4 et versions ultérieures.
Si la même URL doit également ouvrir votre application en tant qu’Universal Link en dehors de la session d’authentification, configurez applinks:example.com et hébergez un fichier apple-app-site-association valide pour le domaine et le chemin.
Ajoutez l’URI HTTPS dans les URI de redirection de votre application Logto.
Passez la même URI à signInWithBrowser.

Sur iOS 17.4 et versions ultérieures, le SDK utilise l’API de correspondance de callback HTTPS de ASWebAuthenticationSession afin que les redirections HTTPS puissent automatiquement terminer et fermer la session. Sur les versions iOS plus anciennes, la requête d’autorisation peut toujours utiliser l’URI de redirection HTTPS, mais la session peut ne pas se fermer automatiquement à moins que votre application ne gère elle-même le callback Universal Link. Gardez une redirection avec schéma personnalisé comme option de compatibilité si vous avez besoin d’une complétion automatique sur les anciennes versions d’iOS.

Passons à la page des détails de l'application de Logto Console. Ajoutez une URI de redirection io.logto://callback et cliquez sur "Enregistrer les modifications".

info:

L’URI de redirection dans le SDK iOS est uniquement à usage interne. Il n’est PAS NÉCESSAIRE d’ajouter un Custom URL Scheme tant qu’un connecteur ne le demande pas.

remarque:

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

En v2, client.signOut(postLogoutRedirectUri:) effectue une déconnexion complète : il efface les identifiants locaux, révoque le jeton de rafraîchissement et termine la session Logto en ouvrant le point de terminaison de fin de session dans le navigateur système. Le navigateur revient ensuite à votre application via l’URI de redirection post-déconnexion. Avant de l’utiliser, allez sur la page de détails de l’application dans Logto Console, ajoutez l’URI de redirection post-déconnexion io.logto.app://signed-out et cliquez sur "Save changes". L’URI de redirection post-déconnexion peut utiliser le même schéma personnalisé que celui enregistré pour la connexion.

Par exemple, dans une application SwiftUI :

ContentView.swift
// Les commentaires dans ce bloc de code peuvent être traduits si nécessaire.
struct ContentView: View {
  @State var isAuthenticated: Bool

  private let redirectUri = "io.logto.app://callback"
  private let postLogoutRedirectUri = "io.logto.app://signed-out"

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            let error = await client.signOut(postLogoutRedirectUri: postLogoutRedirectUri)
            if let error = error {
              print(error)
              return
            }
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: redirectUri)
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // erreur survenue lors de la connexion
            } catch {
              // autres erreurs
            }
          }
        }
      }
    }
  }
}

remarque:

Vous pouvez également appeler client.signOut() sans URI de redirection post-déconnexion. Aucune configuration dans la Console n’est nécessaire dans ce cas : le navigateur affiche la page de déconnexion Logto, et l’utilisateur revient à l’application en la fermant manuellement.
Si aucun contexte d’interface utilisateur n’est disponible, vous pouvez appeler client.clearCredentials() pour effacer les identifiants locaux et révoquer le jeton de rafraîchissement. Notez que cela conserve la session Logto dans le navigateur, donc le prochain signInWithBrowser peut reconnecter l’utilisateur silencieusement via cette session.

Vous pouvez utiliser client.signInWithBrowser(redirectUri:) pour connecter l’utilisateur et client.signOut() pour le déconnecter.

Par exemple, dans une application SwiftUI :

ContentView.swift
// Les commentaires dans ce bloc de code peuvent être traduits si nécessaire.
struct ContentView: View {
  @State var isAuthenticated: Bool

  init() {
    isAuthenticated = client.isAuthenticated
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Button("Sign Out") {
          Task { [self] in
            await client.signOut()
            isAuthenticated = false
          }
        }
      } else {
        Button("Sign In") {
          Task { [self] in
            do {
              try await client.signInWithBrowser(redirectUri: "io.logto://callback")
              isAuthenticated = true
            } catch let error as LogtoClientErrors.SignIn {
              // erreur survenue lors de la connexion
            } catch {
              // autres erreurs
            }
          }
        }
      }
    }
  }
}

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 des informations sur l'utilisateur

Afficher les informations de l'utilisateur

Pour afficher les informations de l'utilisateur, vous pouvez utiliser la méthode client.getIdTokenClaims(). Par exemple, dans une application SwiftUI :

ContentView.swift
struct ContentView: View {
  @State var isAuthenticated: Bool
  @State var name: String?

  init() {
    isAuthenticated = client.isAuthenticated
    name = try? client.getIdTokenClaims().name
  }

  var body: some View {
    VStack {
      if isAuthenticated {
        Text("Bienvenue, \(name)")
      } else {
        Text("Veuillez vous connecter")
      }
    }
  }
}

Demander des revendications supplémentaires

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

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // Par exemple http://localhost:3001
  appId: "<your-app-id>",
  scopes: [
    UserScope.Email.rawValue,
    UserScope.Phone.rawValue,
  ]
)

Ensuite, vous pouvez accéder aux revendications supplémentaires dans la valeur de retour de client.getIdTokenClaims() :

let claims = try? client.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 client.fetchUserInfo() :

let userInfo = try? client.fetchUserInfo()
// Vous pouvez maintenant accéder à la revendication `userInfo.custom_data`

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

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 :

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>", // E.g. http://localhost:3001
  appId: "<your-app-id>",
  resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"], // Ajouter des ressources API
)
let client = LogtoClient(useConfig: config)

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 :

ContentView.swift
let config = try? LogtoConfig(
  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"],
)
let client = LogtoClient(useConfig: config)

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 :

ContentView.swift
let config = try? LogtoConfig(
  endpoint: "<your-logto-endpoint>",
  appId: "<your-app-id>",
  scopes: ["read", "write"],
  resources: ["https://shopping.your-app.com/api", "https://store.your-app.com/api"],
)
let client = LogtoClient(useConfig: config)

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 :

ContentView.swift
let accessToken = try await client.getAccessToken(for: "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.

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.

remarque:

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.

await LogtoRequest.get(
  useSession: session,
  endpoint: userInfoEndpoint,
  headers: ["Authorization": "Bearer \(accessToken)"]
)

Lectures complémentaires

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

Installation​

Carthage​

CocoaPods​

Intégration​

Init LogtoClient​

Implémenter la connexion et la déconnexion​

Concernant la connexion basée sur la redirection​

Configurer l’URI de redirection​

Utiliser Universal Links au lieu d’un schéma personnalisé ?​

Connexion et déconnexion​

Point de contrôle : Testez votre application​

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

Configurer le client Logto​

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

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

Lectures complémentaires​

Installation

Carthage

CocoaPods

Intégration

Init `LogtoClient`

Implémenter la connexion et la déconnexion

Concernant la connexion basée sur la redirection

Configurer l’URI de redirection

Utiliser Universal Links au lieu d’un schéma personnalisé ?

Connexion et déconnexion

Point de contrôle : Testez votre application

Obtenir 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

Configurer le client Logto

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

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

Lectures complémentaires