Pour utiliser les fonctionnalités Client-Initiated Backchannel Authentication (CIBA), vous devez avoir un forfait Enterprise ou un module complémentaire approprié. Consultez la page Tarification Auth0 pour plus de détails.

- Prérequis
- Étape 1 : L’application cliente initie une requête CIBA
- Étape 2 : Le tenant Auth0 accuse réception de la requête CIBA
- Étape 3 : L’application cliente interroge pour obtenir une réponse
- Étape 4 : L’application mobile reçoit la notification push
- É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 renvoie la réponse de l’utilisateur à Auth0
- Étape 8 : Auth0 reçoit la réponse de l’utilisateur une fois le flux terminé
- Étape 9 : Auth0 renvoie un jeton d’accès à l’application cliente
Prérequis
- Configurer Client-Initiated Backchannel Authentication pour votre tenant et votre Application, y compris les notifications push mobiles.
- Définir le paramètre
requested_expirysur une valeur, en secondes, de 300 ou moins. Pour en savoir plus, consultez Configurer le canal de notification.
Étape 1 : L’application cliente initie une requête CIBA
/bc-authorize :
- cURL
- C#
- Go
- Java
| Paramètres | Description |
|---|---|
tenant | Nom du tenant. Il peut aussi s’agir d’un domaine personnalisé. Si le format iss_sub est utilisé, alors le nom du tenant est transmis dans la revendication iss. |
client_id | Identifiant de l’application cliente. |
client_secret | Méthode d’authentification du client utilisée pour l’authentification de l’utilisateur avec CIBA, comme un Secret client, un JWT de clé privée ou l’authentification mTLS. Si vous utilisez un JWT de clé privée ou mTLS, vous n’avez pas besoin d’inclure le Secret client. |
scope | Doit inclure openid.La portée peut, de façon facultative, inclure offline_access pour demander un Jeton d’actualisation. Toutefois, pour une autorisation 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 | ID de l’utilisateur autorisant la demande, qui est transmis dans la structure login_hint. Si le format iss_sub est utilisé, alors l’ID de l’utilisateur est transmis dans la revendication sub.L’ID de l’utilisateur peut avoir un format différent selon le fournisseur externe. |
requested_expiry | Durée maximale, en secondes, pendant laquelle la session CIBA doit être valide. La durée d’expiration demandée pour le flux CIBA est comprise entre 1 et 259200 secondes (72 heures), et sa valeur par défaut est de 300 secondes. Incluez le paramètre requested_expiry pour définir une expiration personnalisée pour le flux CIBA.Le paramètre requested_expiry aide à déterminer quel canal de notification CIBA utilise :
|
binding_message | Message lisible par un humain utilisé pour lier le flux CIBA entre l’appareil d’authentification et l’appareil de consommation. Le message de liaison est obligatoire et peut contenir jusqu’à 64 caractères. Utilisez uniquement des caractères alphanumériques et les caractères +-_.,:#. |
Il existe une limite de débit par utilisateur : l’utilisateur autorisant la demande ne recevra pas plus de 5 requêtes par minute.
Étape 2 : le tenant Auth0 accuse réception de la requête CIBA
POST, vous devriez recevoir une réponse contenant un auth-req-id qui fait référence à la requête :
auth_req_id est transmise au point de terminaison /token pour interroger ce dernier jusqu’à l’achèvement du flux CIBA.
Étape 3 : l’application cliente interroge périodiquement pour obtenir une réponse
/token avec le grant type urn:openid:params:grant-type:ciba et la valeur auth_req_id que vous avez reçue du point de terminaison /bc-authorize :
- cURL
- C#
- Go
- Java
/token.
Étape 4 : L’application mobile reçoit la notification push
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 à partir d’Auth0.
Les extraits de code suivants sont des exemples d’implémentations de notifications push mobiles iOS et Android utilisant la trousse de développement logiciel (SDK) Guardian :
- iOS
- Android
Étape 5 : L’application mobile récupère les détails du consentement
binding_message, à partir de l’API Auth0 Consent.
Si vous utilisez une application personnalisée, les exemples de code suivants sont des implémentations iOS et Android qui récupèrent des données à partir de l’API Auth0 Consent :
- iOS
- Android
Étape 6 : L’application mobile présente les détails du consentement à l’utilisateur
binding_message, la scope et l’audience. Les scopes retournés à l’application mobile sont filtrés selon votre politique RBAC. Pour en savoir plus, consultez Contrôle d’accès basé sur les rôles.
L’application mobile présente la demande d’authentification et/ou les détails du consentement à l’utilisateur.
L’exemple de code suivant illustre une réponse de l’Auth0 Consent API :
Étape 7 : L’application mobile renvoie la réponse de l’utilisateur à Auth0
L’utilisateur accepte la demande d’authentification
- iOS
- Android
L’utilisateur refuse la demande d’authentification
- iOS
- Android
Étape 8 : Auth0 reçoit la réponse de l’utilisateur après l’achèvement du flux
/token. Un flux CIBA exige toujours une réponse, soit une approbation, soit un refus, de la part de l’utilisateur qui autorise, et les autorisations existantes ne sont pas vérifiées.
Étape 9 : Auth0 renvoie le jeton d’accès à l’application cliente
Le
refresh_token ne sera présent que si la portée offline_access a été incluse dans la requête /bc-authorize initiale.