Passer au contenu principal
L’authentification est nouvelle : didit_auth dépend de la version publiée. Les coordonnées de distribution, les versions et les signatures d’appel ne sont pas confirmées ici. N’installez pas un package deviné 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://<slug>.auth.didit.me, ou <slug>.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 app links ; 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. Choisissez votre mise en correspondance stable des personnes avant de connecter la vérification ou la surveillance.
Configurez et testez les liens de rappel séparément sur iOS et Android. La couche d’encapsulation de l’authentification est distincte de didit_sdk, qui gère la vérification.

​
Implémenter le flux hébergé

Ouvrez le navigateur d’authentification natif du système avec l’URL {origin}/sign-in. Fournissez un state aléatoire neuf, un challenge PKCE S256 et votre redirect_uri enregistré. Conservez le vérificateur PKCE dans votre application pour cette seule tentative. Le guide de démarrage JavaScript présente le protocole sous-jacent ; utilisez la cryptographie et la gestion des URL propres à la plateforme plutôt que les globales 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 l’endpoint token/. Utilisez le vérificateur PKCE d’origine et l’URI de redirection exacte. Annuler ou fermer le navigateur n’est pas une connexion réussie. Stockez les tokens de rafraîchissement dans le stockage natif protégé par la plateforme ; jamais dans un fichier de préférences en clair, ni dans les outils d’analyse ou 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 l’état propre à l’utilisateur après la déconnexion. Voir tokens et JWKS pour le contrat des requêtes et le comportement de réutilisation lors du renouvellement.

​
Aperçu de la version du SDK natif

Les modules natifs d’authentification sont prévus pour proposer la connexion, l’accès à la session en cours, la récupération des tokens, la déconnexion et l’élévation du niveau d’authentification, avec des signaux d’appareil automatiques. Les clés d’accès natives et le stockage protégé des tokens font partie de cette version. Les API des wrappers suivront leurs contrats de plateforme publiés ; ne copiez pas d’arguments de constructeur ni de signatures de méthodes devinés à partir d’un exemple de conception. Tant que le module n’est pas publié, gardez son adaptateur désactivé ou utilisez une implémentation vérifiée du protocole hébergé pour votre application activée. Ne présentez pas de guide de démarrage natif d’authentification fonctionnel en vous basant uniquement sur l’installation du package.

​
Connecter la vérification et la surveillance

Votre backend dérive vendor_data de la personne authentifiée. Il crée les sessions de vérification ou émet des tokens de surveillance limités à cette personne. Renvoyez à votre application uniquement l’identifiant d’authentification de session ou le credential de session, ou le token limité ; la clé API reste sur le serveur. Utilisez le SDK de vérification Flutter lorsque vous avez besoin de la vérification d’identité. Suivez la soumission des transactions du SDK pour la prise en charge de la surveillance sur votre plateforme. Traitez séparément les décisions de connexion, de vérification et de transaction.

​
Vérifier l’intégration

Testez le retour à une application arrêtée, les transitions en arrière-plan et au premier plan, l’annulation dans le navigateur, un rappel non concordant, le rejeu d’un code, 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. Un contrôle réalisé uniquement sur appareil reste non vérifié tant qu’il n’a pas été exécuté sur la plateforme cible.
Dernière modification le 7 novembre 2026