Skip to main content
Clés d’identification natives est actuellement proposé en accès anticipé limité. Pour en savoir plus sur les étapes de diffusion d’Auth0, consultez Étapes de la diffusion du produit.
Les clés d’identification sont une forme d’authentification résistante à l’hameçonnage et peuvent remplacer les formes traditionnelles d’authentification (telles que le nom d’utilisateur et le mot de passe); de plus, elles offrent à l’utilisateur une expérience plus facile et mieux sécurisée. Elles sont modélisées à partir des spécifications) FIDO® W3C Web Authentication (WebAuthn) et du protocole client-authentificateur (CTAP). Auth0 prend actuellement en charge les clés d’identification comme méthode d’authentification pour les connexions de base de données et offre deux méthodes d’implémentation : Pour en savoir plus sur la mise en œuvre de clés d’identification pour les applications mobiles, consultez les informations ci-dessous.

Fonctionnement

Les clés d’identification natives utilisent une combinaison du Auth0 Authentication API et des API iOS ou Android natives pour intégrer les flux de défis-réponse directement dans votre application mobile. Cela vous permet de créer une expérience d’inscription et de connexion intégrée pour votre application qui ne repose pas sur la redirection des utilisateurs par leur navigateur pour compléter l’authentification. L’exemple suivant montre ce qu’un nouvel utilisateur peut rencontrer pendant le flux d’inscription avec une clé d’identification :
  1. Un nouvel utilisateur lance votre application mobile et accède à l’écran de connexion. Puisqu’il s’agit d’un nouvel utilisateur, il sélectionne le bouton Sign Up (Inscription).
  2. Sur l’écran suivant, l’utilisateur saisit son adresse courriel et sélectionne Create Account (Créer un compte).
  3. Ensuite, l’utilisateur est invité à créer une clé d’identification pour votre application. Il sélectionne donc Continue (Continuer).
  4. Pour générer une clé d’identification, l’utilisateur doit s’authentifier localement sur son appareil à l’aide des données biométriques ou d’une autre méthode d’authentification, telle que la saisie d’un NIP.
  5. Une fois l’authentification locale terminée, une nouvelle clé d’identification est enregistrée sur l’appareil de l’utilisateur et cette clé est synchronisée avec son fournisseur de clé d’identification, tel qu’iCloud ou Google.
  6. Une fois la clé d’identification enregistrée, l’utilisateur poursuit le processus d’enregistrement du nouvel utilisateur pour finaliser son compte.
Par la suite, l’utilisateur pourra s’authentifier avec sa clé d’identification enregistrée au moment de se connecter à votre application.

Avant de commencer

Configuration d’un domaine personnalisé

Les clés d’identification natives nécessitent l’utilisation d’un domaine personnalisé. Avant de continuer, assurez-vous d’avoir configuré un domaine personnalisé pour votre locataire. Pour en savoir plus, consultez l’article Domaines personnalisés.

Configuration de votre politique de clé d’identification

Avant de pouvoir implémenter des clés d’identification natives pour les applications Android ou iOS, vous devez configurer une politique de clé d’identification dans votre locataire Auth0. Pour préparer votre locataire, suivez les étapes décrites dans l’article Configurer la politique de clés d’identification.

Préparation de votre application

Pour préparer votre application aux clés d’identification natives, vous devez configurer les paramètres de votre appareil et ajouter l’autorisation Passkey (Clé d’identification). Vous pouvez terminer ces configurations dans votre ou en utilisant .

Auth0 Dashboard

  1. Accédez à Applications > Applications et sélectionnez l’application que vous souhaitez mettre à jour.
  2. En bas de l’onglet Settings (Réglages), sélectionnez Advanced Settings (Réglages avancés). Choisissez ensuite l’onglet Device Settings (Réglages de l’appareil).
  3. Remplissez les sections iOS et Android nécessaires pour votre application. Cliquez ensuite sur Save Change (Enregistrer les modifications).
  4. Dans la section Réglages avancés, sélectionnez l’onglet Types d’autorisation.
  5. Activez l’autorisation Passkey (Clé d’identification), puis sélectionnez Save Change (Enregistrer les modifications).

Management API

Appelez le point de terminaison Update a Client (Mettre à jour un client) et :
  • Mettez à jour grant_types pour inclure urn:okta:params:oauth:grant-type:webauthn.
  • Utilisez l’objet mobile pour spécifier les paramètres de l’appareil iOS et Android selon vos besoins.

Implémentation des flux de clé d’identification

Vous pouvez définir les flux de clé d’identification suivants pour votre application :
  • Flux d’inscription : Permet aux nouveaux utilisateurs de générer et d’enregistrer une clé d’identification pendant le processus d’enregistrement de l’utilisateur.
  • Flux de connexion : Permet à un utilisateur existant qui s’est déjà inscrit avec la méthode de clé d’identification de se connecter en s’authentifiant avec sa clé d’identification enregistrée.

Flux d’inscription

Un utilisateur lance le flux d’inscription par clé d’identification lorsqu’il tente pour la première fois de se connecter à votre application. Si l’utilisateur fournit un identifiant qui existe déjà, il est recommandé de l’inviter à terminer le flux de connexion. Sinon, l’action échouera.

Étapes du flux

  1. Un utilisateur visite votre application et choisit d’enregistrer un nouveau compte. L’utilisateur fournit un identifiant demandé par votre application, tel que son adresse courriel.
  2. Votre application lance ensuite le défi-réponse d’inscription en appelant le point de terminaison Demander un défi-réponse d’inscription d’Auth0 Authentication API :
    • Si vous ne spécifiez pas de realm, le répertoire par défaut de votre locataire est utilisé.
    • Par défaut, le courriel est l’identifiant requis. Si vous avez activé Identifiants flexibles pour votre connexion de base de données, vous pouvez utiliser une combinaison de email, phone_number, ou username à la place. Ces options peuvent être obligatoires ou facultatives et doivent correspondre à votre configuration d’identificateur flexible.
    POST /passkey/register
    Content-Type: application/json
    
    {
      "client_id": "<CLIENT_ID>",
      "realm": "<OPTIONAL_CONNECTION>",
      "user_profile": {
    	  "email": "<VALID_EMAIL_ADDRESS>",
    	  "name": "<OPTIONAL_USER_DISPLAY_NAME>",
      }
    }
    
  3. En réponse, Auth0 renvoie PublicKeyCredentialCreationOptions avec un identifiant auth_session :
    HTTP/1.1 200 OK
    Content-Type: application/json
    
    {
      "authn_params_public_key": {
        "challenge": "<GENERATED_CHALLENGE_FOR_THIS_SESSION>",
        "timeout": <MILLISECONDS>,
        "rp": {
          "id": "<THE_CUSTOM_DOMAIN>",
          "name": "<THE_CUSTOM_DOMAIN>"
        },
        "pubKeyCredParams": [
          { type: 'public-key', alg: -8 },
          { type: 'public-key', alg: -7 },
          { type: 'public-key', alg: -257 }
        ],
        "authenticatorSelection": {
          "residentKey": "required",
          "userVerification": "preferred"
        },
        "user": {
          "id": "<GENERATED_ID>",
          "name": "<USER-ENTERED_IDENTIFIER>",
          "displayName": "<USER-ENTERED_DISPLAY_NAME_OR_IDENTIFIER_IF_MISSING>"
        }
      },
      "auth_session": "<SESSION_ID>"
    }
    
  4. Votre application termine ensuite le processus d’enregistrement de l’utilisateur à l’aide des API natives appropriées :
  5. Votre application utilise ensuite les identifiants obtenus lors du processus d’enregistrement, y compris les détails authn_response, pour appeler le point de terminaison Jeton :
    POST /oauth/token
    Content-Type: application/json
    
    {
      "grant_type": "urn:okta:params:oauth:grant-type:webauthn",
      "client_id": "<CLIENT_ID>",
      "realm": "<OPTIONAL_CONNECTION>",
      "scope": "<OPTIONAL_REQUESTED_SCOPE>",
      "audience": "<OPTIONAL_REQUESTED_AUDIENCE>"
      "auth_session": "<SESSION_ID_FROM_THE_FIRST_REQUEST>",
      "authn_response": {
        "id": "<BASE64URL_ID>",
        "rawId": "<BASE64URL_RAWID>",
        "type": "public-key",
        "authenticatorAttachment": "platform|cross-platform",
        "response": {
          "clientDataJSON": "<BASE64URL_CLIENT_DATA_JSON>",
          "attestationObject": "<BASE64URL_ATTESTATION_OBJECT>",
          <OTHER_PROPERTIES>
        }  
    }
    
  6. Auth0 crée un nouveau compte utilisateur et renvoie les jetons demandés pour compléter le flux :
    HTTP/1.1 200 OK
    Content-Type: application/json
    
    {
      "access_token": "<BASE64_TOKEN>",
      "refresh_token": "<BASE64_TOKEN>",
      "id_token": "<BASE64_TOKEN>",
      "token_type": "Bearer",
      "expires_in": <SECONDS>
    }
    

Flux de connexion

Un utilisateur existant lance le flux de connexion par clé d’identification lorsqu’il tente de se connecter à votre application. Ce flux s’applique uniquement aux utilisateurs existants qui ont enregistré une clé d’identification à leurs comptes lors de l’inscription initiale.

Étapes du flux

  1. Un utilisateur lance votre application et commence le processus de connexion. Votre application lance ensuite le défi-réponse de connexion en appelant le point de terminaisonDemander un défi-réponse de connexion d’Authentication API :
    Si vous ne spécifiez pas de realm, le répertoire par défaut de votre locataire est utilisé.
    POST /passkey/challenge
    Content-Type: application/json
    
    {
      "client_id": "<CLIENT_ID>",
      "realm": "<OPTIONAL_CONNECTION>"
    }
    
  2. En réponse, Auth0 renvoie PublicKeyCredentialRequestOptions avec l’objet auth_session pour continuer le flux dans votre application :
    HTTP/1.1 200 OK
    Content-Type: application/json
    
    {
      "authn_params_public_key": {
        "challenge": "<GENERATED_CHALLENGE_FOR_THIS_SESSION>",
        "timeout": <AUTH_TIMEOUT_IN_MILLISECONDS>,
        "rpId": "<CUSTOM_DOMAIN>",
        "userVerification": "preferred"
      },
      "auth_session": "<SESSION_ID>"
    }
    
  3. Votre application termine ensuite le processus de connexion en utilisant les API natives appropriées :
  4. Votre application utilise ensuite les identifiants obtenus lors du processus de connexion, y compris les détails authn_response, pour appeler le point de terminaisonJeton :
    POST /oauth/token
    Content-Type: application/json
    
    {
      "grant_type": "urn:okta:params:oauth:grant-type:webauthn",
      "client_id": "<CLIENT_ID>",
      "realm": "<OPTIONAL_CONNECTION>",
      "scope": "<OPTIONAL_REQUESTED_SCOPE>",
      "audience": "<OPTIONAL_REQUESTED_AUDIENCE>"
      "auth_session": "<SESSION_ID_FROM_THE_FIRST_REQUEST>",
      "authn_response": {
        "id": "<BASE64URL_ID>",
        "rawId": "<BASE64URL_RAWID>",
        "type": "public-key",
        "authenticatorAttachment": "platform|cross-platform",
        "response": {
          "authenticatorData": "<BASE64URL_AUTHENTICATORDATA>",
          "clientDataJSON": "<BASE64URL_CLIENTDATAJSON>",
          "signature": "<BASE64URL_SIGNATURE>",
          "userHandle": "<BASE64URL_USERHANDLE>"
        },
        "clientExtensionResults": <OPTIONAL_OBJECT>
    }
    
  5. Auth0 authentifie les identifiants de connexion et renvoie les jetons demandés pour compléter le flux :
    HTTP/1.1 200 OK
    Content-Type: application/json
    
    {
      "access_token": "<BASE64_TOKEN>",
      "refresh_token": "<BASE64_TOKEN>",
      "id_token": "<BASE64_TOKEN>",
      "token_type": "Bearer",
      "expires_in": <SECONDS>
    }
    

Références

Les ressources suivantes peuvent être référencées lors de l’implémentation de clés d’identification natives pour votre application mobile :