> ## 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. # Authentification : connexion, passkeys et sessions > Ajoutez la connexion des utilisateurs avec Didit : pages hébergées, passkeys, codes, SSO et réseaux sociaux, liée à la vérification d'identité. > [!WARNING] > > Authentication est une nouveauté. Didit active le produit pour votre application. Tant que ce n'est pas fait, toutes les routes d'exécution de cette application renvoient `404`. Les packages du SDK Authentication ne sont pas encore publiés : utilisez donc le flux hébergé et le contrat HTTP décrits dans ces pages. Authentication permet à vos clients de se connecter à **votre application**. Ce service est distinct de la connexion à la console Didit ou de la création d'un compte développeur Didit. Il est aussi distinct de la vérification de l'identité d'une personne. Utilisez Authentication seul, ou combinez-le avec la Vérification d'identité et la Surveillance des transactions. La connexion n'approuve pas une vérification et n'autorise pas un paiement. Votre back-end prend ces décisions à partir du résultat propre à chaque produit. ## Fonctionnement Chaque application dispose de sa propre origine de connexion et de son propre émetteur de tokens. Les applications de production et les applications sandbox sont séparées : elles ont des origines, des paramètres et des identités distincts. | Élément | Valeur | | - | - | | Origine par défaut | `https://.auth.didit.me` pour une application de production, `https://.sandbox.auth.didit.me` pour une application sandbox. La console affiche la vôtre. Un domaine personnalisé vérifié peut la remplacer. | | Pages hébergées | `/sign-in`, `/magic`, `/invite` et `/reset` sur cette origine. | | API d'exécution | La même origine, par exemple `POST {origin}/token/` et `GET {origin}/session/`. | | Émetteur | L'origine elle-même. La découverte se trouve à `{origin}/.well-known/openid-configuration`. | | Clé publiable | `pk_live_...` ou `pk_test_...`. Elle identifie l'application et n'est pas un secret. | Le flux est le code d'autorisation OAuth 2.0 avec PKCE (`S256` uniquement) : 1. Votre application ouvre `{origin}/sign-in` avec `redirect_uri`, `state`, `code_challenge` et `code_challenge_method=S256`. 2. La page hébergée connecte ou inscrit la personne avec les méthodes que vous avez activées, y compris tout second facteur requis. 3. Le navigateur revient vers votre `redirect_uri` avec `code` et `state`. 4. Votre application échange le code à `POST {origin}/token/` contre un token d'accès, un token ID et un token de rafraîchissement. Consultez [tokens et JWKS](https://docs.didit.me/fr/authentication/tokens-and-jwks.md) pour le contrat des tokens, et [méthodes de connexion](https://docs.didit.me/fr/authentication/sign-in-methods.md) pour chaque méthode. ## Choisissez votre plateforme > [card] [JavaScript](https://docs.didit.me/fr/authentication/quickstarts/javascript.md) > > Connexion hébergée, rappel, session et déconnexion. > [card] [React](https://docs.didit.me/fr/authentication/quickstarts/react.md) > > État côté client et vues d'application protégées. > [card] [Next.js](https://docs.didit.me/fr/authentication/quickstarts/nextjs.md) > > Sessions côté serveur, routes de rappel et cookies. > [card] [iOS](https://docs.didit.me/fr/authentication/quickstarts/ios.md) > > Navigateur système et stockage sécurisé des tokens. > [card] [Android](https://docs.didit.me/fr/authentication/quickstarts/android.md) > > Autorisation par navigateur et rappels de l'application. > [card] [React Native](https://docs.didit.me/fr/authentication/quickstarts/react-native.md) > > Préparation d'un adaptateur d'authentification natif. > [card] [Flutter](https://docs.didit.me/fr/authentication/quickstarts/flutter.md) > > Préparation d'un adaptateur d'authentification natif. ## Préparez votre application 1. Demandez à Didit d'activer Authentication pour votre application. Testez d'abord dans une application sandbox. 2. Enregistrez vos [URL de redirection](#url-de-redirection) exactes (jusqu'à 50) ainsi que les `allowed_origins` du navigateur (jusqu'à 50) qui appellent l'API d'exécution. 3. Activez les [méthodes de connexion](https://docs.didit.me/fr/authentication/sign-in-methods.md) que vous souhaitez proposer. Didit ID Wallet est toujours activé. 4. Choisissez vos paramètres de session et de mot de passe (voir ci-dessous). 5. Testez l'inscription, la connexion, le mot de passe oublié, l'authentification multifacteur, l'expiration de session et la déconnexion avant la mise en production. Une clé d'accès est liée à son origine. Si vous activez plus tard un domaine personnalisé, les utilisateurs devront enregistrer de nouveau leurs clés d'accès. ## URL de redirection Didit ne renvoie une personne que vers une adresse que vous avez enregistrée. Enregistrez la vôtre dans la console, sous **Authentication > Security and sessions > Redirect URLs and allowed origins**. Le `redirect_uri` d'une requête de connexion doit correspondre caractère par caractère à une URL enregistrée : schéma, hôte, port, chemin et requête. Un port différent, une barre oblique finale ou une casse différente désignent une autre adresse. | Application | Ce que vous pouvez enregistrer | | - | - | | Production | Des URL `https://` | | Sandbox | Des URL `https://`, et des URL `http://` sur `localhost`, `127.0.0.1` ou `[::1]` | Les caractères génériques, les fragments, les identifiants dans l'URL et les schémas personnalisés sont rejetés. Lorsque l'adresse n'est pas enregistrée, Didit ne redirige jamais vers elle. `{origin}/sign-in` répond `400` avec une page indiquant quoi enregistrer et où, et `POST {origin}/authorize/` répond `400 {"error": "invalid_redirect_uri"}`. ### Développement local Testez sur votre propre machine avec votre application sandbox : 1. Enregistrez votre URL de rappel avec son port, par exemple `http://localhost:3000/auth/callback`. 2. Si du code de navigateur appelle l'API d'exécution, par exemple pour échanger le code à `POST {origin}/token/`, ajoutez aussi l'origine dans **Allowed origins** : `http://localhost:3000`, sans chemin ni barre oblique finale. 3. Lancez la connexion sur l'origine de votre sandbox, `https://.sandbox.auth.didit.me`, avec votre clé `pk_test_...`. `localhost`, `127.0.0.1` et `[::1]` sont des adresses distinctes, et chaque port l'est aussi. Enregistrez chacune de celles que vous utilisez. Les applications de production n'acceptent jamais `http://`. Avant la mise en production, enregistrez votre URL de rappel `https://` de production dans votre application de production. ## Paramètres de l'application Vous gérez ces paramètres dans la console, ou avec une session de console autorisée disposant de `write:authentication`. | Paramètre | Valeurs | Valeur par défaut | | - | - | - | | `session_lifetime` | `86400`, `604800`, `2592000`, `7776000` secondes | `2592000` (30 jours) | | `idle_timeout` | `1800`, `7200`, `86400`, `604800` secondes | `86400` (1 jour) | | `multiple_sessions` | `false` déconnecte la personne de ses autres sessions à chaque nouvelle connexion | `true` | | `password_min_length` | `8`, `10`, `12`, `14` | `10` | | `revoke_on_password_change` | Met fin à toutes les sessions après une réinitialisation du mot de passe | `true` | | `signup_policy` | `anyone`, `invited`, `allowed_domains` (avec `allowed_email_domains`, jusqu'à 100) | `anyone` | | `allow_subaddresses` | Accepter un `+` dans la partie locale de l'e-mail | `false` | | `post_logout_redirect_uri` | Adresse vers laquelle votre application envoie la personne après la déconnexion | Vide | | `mfa_policy` | `optional`, `everyone`, `organization_admins` | `organization_admins` | | `sign_in_ui` | `hosted` ou `own` | `hosted` | ## Garder une même personne entre les produits Chaque identité porte une valeur `vendor_data`. Il s'agit de l'`external_id` que vous avez fourni lors de l'[importation](https://docs.didit.me/fr/authentication/migration.md) de la personne, ou de l'identifiant d'identité Didit sinon. Elle apparaît dans le token d'accès, le token d'identité et `GET session/`. Utilisez la même valeur comme `vendor_data` lorsque vous créez des sessions de vérification et soumettez des transactions. Les événements d'authentification sont alors rattachés à la même personne dans la console que ses vérifications et transactions. Consultez [événements et webhooks](https://docs.didit.me/fr/authentication/events-and-webhooks.md). Dérivez `vendor_data` sur votre backend à partir d'un token vérifié, jamais à partir d'un champ de navigateur non vérifié. | Combinaison de produits | Ce que vous construisez | | - | - | | Authentification | Se connecter, valider les sessions et se déconnecter. | | Vérification d'identité + Authentification | Démarrer une vérification après la connexion lorsque votre politique l'exige, avec le `vendor_data` du token. | | Surveillance des transactions + Authentification | Soumettre les transactions pour le `vendor_data` de la personne connectée. Les événements de connexion sont associés à la chronologie et aux règles de cette même personne. | | Les trois | Un `vendor_data` par personne. Traitez la décision de chaque produit séparément. | Utilisez le [prompt d'intégration partagé](https://docs.didit.me/fr/integration/integration-prompt.md) pour toute combinaison. Consultez [protection contre les bots](https://docs.didit.me/fr/authentication/bot-protection.md) pour les politiques exécutées lors de la connexion. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.