Authentification des utilisateurs avec CIBA

Apprenez à authentifier les utilisateurs à l’aide du flux d’authentification par canal d’appui initié par le client.

L’authentification CIBA est actuellement en accès anticipé. Pour activer l’authentification CIBA, communiquez avec votre Gestionnaire de compte technique.

L’authentification par canal d’appui initiée par le client (CIBA) ne repose pas sur une application client qui redirige l’utilisateur via le navigateur pour effectuer le processus de connexion/d’authentification. Au lieu de cela, l’application client appelle directement le fournisseur OpenID par le biais d’une demande par canal d’appui pour lancer le flux d’authentification.

Le schéma de séquences suivant illustre une mise en œuvre du flux CIBA :

Deux éléments sont définis : un utilisateur autorisant et un utilisateur initiant. L’utilisateur autorisant et l’utilisateur initiant peuvent être deux personnes différentes, par exemple un utilisateur qui appelle un centre d’appel et un agent d’un centre d’appel. Dans d’autres cas d’utilisation, il peut s’agir de la même personne, par exemple un utilisateur qui s’authentifie auprès d’un kiosque de vente au détail ou d’un autre appareil connecté.

Les sections suivantes expliquent étape par étape comment fonctionne l’authentification de l’utilisateur avec le flux CIBA :

• Conditions préalables
• Étape 1 - L’application client initie une demande CIBA
• Étape 2 - Le locataire Auth0 accuse réception de la demande CIBA
• Étape 3 - L’application client demande une réponse
• Étape 4 - L’application mobile reçoit la notification poussée
• Étape 5 - L’application mobile récupère les détails du consentement
• Étape 6 - L’application mobile présente les détails du consentement à l’utilisateur
• Étape 7 - L’application mobile envoie la réponse de l’utilisateur à Auth0
• Étape 8 - Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé

​

Conditions préalables

Pour initier une requête CIBA poussée, l’utilisateur autorisant doit être inscrit à la MFA en utilisant les notifications poussées. Pour vérifier dans Auth0 Dashboard, naviguez vers User Management (Gestion des utilisateurs) > Users (Utilisateurs) et cliquez sur l’utilisateur :

Si vous avez défini l’authentification multifacteur (MFA) comme obligatoire pour votre locataire, les utilisateurs sont invités à s’inscrire à la MFA lors de leur prochaine connexion. Vous pouvez également utiliser des Actions pour demander l’inscription à la MFA.

Les notifications poussées pour la MFA sont généralement mises en œuvre dans une application mobile personnalisée qui intègre la trousse SDK Guardian. Pour en savoir plus, lisez Configurer une authentification par canal d’appui initiée par le client.

​

Étape 1 - L’application client initie une demande CIBA

Utilisez les User Search API (API de recherche d’utilisateurs) pour trouver l’utilisateur autorisé pour lequel vous souhaitez lancer une demande CIBA et obtenir son identifiant utilisateur.

Une fois que vous avez l’identifiant de l’utilisateur autorisant, utilisez l’Authentication API ou nos trousses SDK pour envoyer une demande CIBA au point de terminaison /bc-authorize :

cURL

curl --location 'https://$tenant.auth0.com/bc-authorize' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=$client_id' \
  --data-urlencode 'client_secret=$client_secret' \
  --data-urlencode 'login_hint={ "format": "iss_sub", "iss": "https://$tenant.auth0.com/", "sub": "$user_id" }' \
  --data-urlencode 'scope=$scope' \
  --data-urlencode 'binding_message=$binding_message'

Parameters	Description
TENANT	Nom du locataire. Il peut également s’agir d’un domaine personnalisé.
CLIENT ID	ID client de l’application
CLIENT SECRET	Méthode d’authentification du client utilisée pour l’authentification de l’utilisateur avec CIBA, telle que Secret Client, Clé privée JWT ou Authentification mTLS.
SCOPE	Doit inclure un openid. La permission peut inclure offline_access en option pour demander un jeton d’actualisation. Cependant, pour l’autorisation à usage unique d’une transaction avec le flux CIBA, un jeton d’actualisation n’est pas nécessaire et n’a aucune signification dans ce contexte.
USER ID	Identifiant utilisateur pour l’utilisateur faisant autorité qui est passé dans la structure login_hint. L’identifiant utilisateur d’une connexion fédérée peut avoir un format différent.
EXPIRY	L’expiration demandée du flux CIBA est comprise entre 1 et 300 secondes, et elle est par défaut de 300 secondes.
BINDING MESSAGE	Message utilisé pour lier le flux CIBA entre les dispositifs d’authentification et de consommation. Le message de liaison est requis et peut contenir jusqu’à 64 caractères. Utilisez uniquement les caractères alphanumériques et +-_.,:#
AUDIENCE	Identifiant unique du public pour un jeton émis.

Il existe une limite anti-attaques spécifique à l’utilisateur, selon laquelle l’utilisateur autorisé ne recevra pas plus de 5 demandes par minute.

​

Étape 2 - Le locataire Auth0 accuse réception de la demande CIBA

Si le locataire Auth0 reçoit avec succès la requête POST, vous devriez recevoir une réponse contenant un auth-req-id qui référence la requête :

{
    "auth_req_id": "eyJh...",
    "expires_in": 300,
    "interval": 5
}

La valeur auth_req_id est transmise au point de terminaison /token pour vérifier l’achèvement du flux CIBA.

​

Étape 3 - L’application client demande une réponse

Utilisez l’Authentication API ou nos trousses SDK pour appeler le point de terminaison /token en utilisant le type d’autorisation urn:openid:params:grant-type:ciba et le auth_req_id que vous avez reçu du point de terminaison /bc-authorize :

cURL

curl --location 'https://$tenant.auth0.com/oauth/token' \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data-urlencode 'client_id=$client_id' \
  --data-urlencode 'client_secret=$client_secret' \
  --data-urlencode 'auth_req_id=$auth_req_id' \
  --data-urlencode 'grant_type=urn:openid:params:grant-type:ciba'

Jusqu’à ce que l’utilisateur autorisant la transaction l’approuve, vous devriez recevoir la réponse suivante :

{
    "error": "authorization_pending",
    "error_description": "The end-user authorization is pending"
}

L’intervalle d’attente pour la demande est d’environ cinq secondes. Si vous interrogez trop fréquemment, vous recevrez la réponse suivante, dont la description varie en fonction de l’intervalle d’attente :

{
"error": "slow_down",
"error_description": "You are polling faster than allowed. Try again in 10 seconds."
}

Pour résoudre l’erreur, attendez le prochain intervalle (en secondes) pour interroger le point de terminaison /token.

​

Étape 4 - L’application mobile reçoit la notification poussée

Auth0 envoie une notification poussée à l’application mobile ou à l’appareil enregistré de l’utilisateur. La trousse SDK Guardian fournit des méthodes pour analyser les données reçues de la notification poussée et retourner une instance Notification prête à l’emploi. L’instance Notification comprend un identifiant de liaison de transaction, ou txlinkid, que l’application mobile utilise pour récupérer les détails du consentement auprès d’Auth0.

Les exemples de code suivants sont des exemples d’implémentations de notifications poussées mobiles iOS et Android utilisant la trousse SDK Guardian :

iOS

//implementing UNUserNotificationCenterDelegate
func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: (UNNotificationPresentationOptions) -> Void) {
    let userInfo = notification.request.content.userInfo
    if let notification = Guardian.notification(from: userInfo) {
         // Implement this function to display the prompt and handle user's consent/rejection.
         handleGuardianNotification(notification: notification)
    }
}

​

Étape 5 - L’application mobile récupère les détails du consentement

Appelez la trousse SDK Guardian à partir de votre application mobile pour récupérer les détails du consentement, c’est-à-dire le contenu de binding_message depuis l’Auth0 Consent API.

Les exemples de code suivants sont des exemples d’implémentations iOS et Android qui récupèrent les données depuis Auth0 Consent API :

iOS

let device: AuthenticationDevice = // the object you obtained during the initial Guardian SDK enrollment process and stored locally
if let consentId = notification.transactionLinkingId {
    Guardian
        .consent(forDomain: {yourTenantDomain}, device: device)
        .fetch(consentId: consentId, notificationToken: notification.transactionToken)
        .start{result in
            switch result {
            case .success(let payload):
                // present consent details to the user
            case .failure(let cause):
                // something went wrong
        }
    }
}

​

Étape 6 - L’application mobile présente les détails du consentement à l’utilisateur

L’Auth0 Consent API envoie à l’application mobile une réponse contenant le binding_message ou les détails du consentement. L’application mobile présente la demande d’authentification et/ou les détails du consentement à l’utilisateur.

L’exemple de code suivant est un exemple de réponse de l’Auth0 Consent API :

{
  "id": "cns_abc123",
  "requested_details": {
    "audience": "https://$tenant.auth0.com/userinfo",
    "scope": ["openid"],
    "binding_message": "21-49-38"
  },
  "created_at": 1746693720
  "expires_at": 1746693750
}

L’utilisateur peut accepter ou refuser la demande d’authentification à ce stade.

​

Étape 7 - L’application mobile envoie la réponse de l’utilisateur à Auth0

Selon que l’utilisateur accepte ou rejette la demande d’authentification, l’application mobile renvoie la réponse de l’utilisateur à Auth0.

Les exemples de code suivants sont des implémentations iOS et Android qui traitent la réponse de l’utilisateur :

​

L’utilisateur accepte la demande d’authentification

iOS

Guardian
    .authentication(forDomain: "{yourTenantDomain}", device: device)
    .allow(notification: notification)
    // or reject(notification: notification, withReason: "hacked")
    .start { result in
        switch result {
        case .success:
            // the auth request was successfully rejected
        case .failure(let cause):
            // something failed, check cause to see what went wrong
        }
    }

​

L’utilisateur rejette la demande d’authentification

iOS

Guardian
        .authentication(forDomain: "{yourTenantDomain}", device: device)
        .reject(notification: notification)
        // or reject(notification: notification, withReason: "hacked")
        .start { result in
            switch result {
            case .success:
                // the auth request was successfully rejected
            case .failure(let cause):
                // something failed, check cause to see what went wrong
            }
        }

​

Étape 8 - Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé

L’application client termine l’interrogation après avoir reçu une réponse du point de terminaison /token. Un flux CIBA nécessite toujours une réponse, soit une approbation, soit un refus, de la part de l’utilisateur qui a donné l’autorisation, et les autorisations existantes ne sont pas vérifiées.

Si l’utilisateur rejette la requête poussée, vous devriez recevoir la réponse suivante :

{
    "error": "access_denied",
    "error_description": "The end-user denied the authorization request or it has been expired"
}

Si l’utilisateur approuve la requête poussée, vous devriez recevoir la réponse suivante :

{
    "access_token": "eyJh...",
    "id_token": "eyJh...",
    "expires_in": 86400,
    "scope": "openid",
    "token_type": "Bearer"
}

​

En savoir plus

• Flux d’authentification par canal d’appui initié par le client
• Configurer l’authentification par canal d’appui initiée par le client