> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Démarrage rapide iOS : authentification Didit > Préparez l'authentification iOS avec Didit : connexion hébergée, validation des rappels, sessions sécurisées, liens vers la vérification. > [!WARNING] > > L'authentification est nouvelle : **DiditAuth pour iOS** dépend de la version publiée. Les coordonnées de distribution, les numéros de version et les signatures d'appel ne sont pas confirmés ici. N'installez pas un package supposé ou choisi au hasard et n'utilisez pas le SDK de vérification d'identité comme SDK d'authentification. ## Préparer l'application 1. Confirmez que l'authentification est activée pour votre application Didit et copiez son origine de connexion (`https://.auth.didit.me`, ou `.sandbox.auth.didit.me` pour le sandbox) depuis la console. 2. Enregistrez une URL de rappel exacte, prise en charge par votre application et par l'environnement d'exécution. Validez la propriété des liens d'application ; ne supposez pas que des schémas d'URL personnalisés arbitraires sont acceptés. 3. Séparez la configuration sandbox et production, y compris la gestion des rappels et les identifiants stockés. 4. Définissez la correspondance stable avec la personne avant de connecter la vérification ou la surveillance. Utilisez la session d'authentification du système pour la connexion hébergée. Prévoyez ensemble la gestion native des passkeys et le domaine de la partie de confiance (relying party) ; une WebView ne remplace pas le flux d'authentification du système. ## Implémenter le flux hébergé Ouvrez une session d'authentification du navigateur système avec l'URL `{origin}/sign-in`. Fournissez un `state` nouvellement généré, un challenge PKCE S256 et votre `redirect_uri` enregistré. Conservez le vérificateur dans votre application pour cette seule tentative. Le [guide de démarrage JavaScript](https://docs.didit.me/fr/authentication/quickstarts/javascript.md) présente le protocole sous-jacent ; utilisez la cryptographie et la gestion des URL propres à la plateforme plutôt que les objets globaux du navigateur dans le code natif. Au retour, vérifiez le state, la durée de validité de la transaction et la destination du rappel avant d'échanger le code à usage unique auprès de `token/`. Utilisez le vérificateur d'origine et l'URI de redirection exacte. Annuler ou fermer le navigateur n'est pas une connexion réussie. Stockez les tokens de renouvellement dans un stockage d'identifiants protégé par la plateforme ; ne les placez jamais dans un fichier de préférences en clair, dans les outils d'analyse ou dans les journaux de plantage. Validez la session en cours avec `GET session/` et le Bearer token de l'utilisateur final. Sérialisez le renouvellement, remplacez les deux tokens ensemble et effacez les états propres à l'utilisateur après la déconnexion. Consultez [tokens et JWKS](https://docs.didit.me/fr/authentication/tokens-and-jwks.md) pour le contrat de requête et le comportement en cas de réutilisation d'un token de renouvellement. ## Aperçu de la préversion du SDK natif Les modules natifs d'authentification sont prévus pour fournir la connexion, l'accès à la session en cours, la récupération des tokens, la déconnexion et le renforcement de l'authentification, avec des signaux automatiques de l'appareil. Les clés d'accès natives et le stockage protégé des tokens font partie de cette version. Les API d'encapsulation suivront leurs contrats de plateforme publiés ; ne copiez pas de constructeurs ni de signatures de méthodes supposés à partir d'un exemple de conception. Tant que le module n'est pas publié, désactivez son adaptateur ou utilisez une implémentation vérifiée du protocole hébergé pour votre application activée. Ne présentez pas comme fonctionnel un démarrage rapide natif d'authentification qui repose uniquement sur l'installation d'un package. ## Connecter la vérification et la surveillance Votre backend dérive `vendor_data` de la personne authentifiée. Il crée des sessions de vérification ou génère des tokens de surveillance limités à cette personne. Ne renvoyez à votre application que l'identifiant d'authentification de session ou le token limité ; la clé API reste sur le serveur. Utilisez le [SDK de vérification iOS](https://docs.didit.me/fr/integration/native-sdks/ios-sdk.md) lorsque vous avez besoin de la vérification d'identité. Suivez [la soumission des transactions via le SDK](https://docs.didit.me/fr/transaction-monitoring/sdk-transaction-submission.md) pour la prise en charge de la surveillance sur votre plateforme. Traitez séparément la connexion, la vérification et les décisions sur les transactions. ## Vérifier l'intégration Testez le retour sur une application relancée à froid, les transitions en arrière-plan et au premier plan, l'annulation du navigateur, un rappel qui ne correspond pas, la réutilisation d'un code déjà consommé, l'expiration des tokens, le renouvellement concurrent, la MFA, la déconnexion et la connexion d'un autre utilisateur. Testez l'enregistrement et la connexion par passkey sur les appareils pris en charge, une fois cette version disponible. Une vérification effectuée uniquement sur un appareil reste non vérifiée tant qu'elle n'a pas été exécutée sur la plateforme cible. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.