Connexion par canal arrière

Envoyez une requête d’authentification directement à l’appareil enregistré d’un utilisateur au moyen du flux de connexion par canal arrière CIBA.

​

Endpoint

POST /bc-authorize

Le endpoint connexion par canal arrière permet aux applications d’envoyer une requête d’authentification vers le téléphone d’un utilisateur, ou vers l’appareil d’authentification, à condition qu’une application y soit installée et que l’utilisateur soit inscrit pour les notifications push à l’aide du Guardian SDK.

Utilisez le endpoint connexion par canal arrière pour authentifier les utilisateurs dans les cas d’utilisation suivants :

• Les utilisateurs ne sont pas devant l’application qui exige une authentification, par exemple lorsqu’ils téléphonent à un centre d’appels.
• L’appareil utilisé pour accéder au service, ou l’appareil qui permet à l’utilisateur d’utiliser un service, n’est pas sécuritaire pour les opérations sensibles (p. ex., un navigateur Web pour des transactions financières).
• L’appareil utilisé pour accéder au service a des capacités d’interaction limitées (p. ex., des vélos électriques ou des trottinettes électriques).

​

Corps de la réponse

Si la requête aboutit, vous devriez recevoir une réponse semblable à celle-ci :

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

La valeur auth_req_id doit être conservée, car elle est utilisée plus tard dans le flux pour identifier la requête d’authentification.

La valeur expires_in vous indique combien de secondes il vous reste avant que la requête d’authentification n’expire.

La valeur interval vous indique combien de secondes vous devez attendre entre chaque requête de vérification.

La requête doit être approuvée ou rejetée sur l’appareil d’authentification de l’utilisateur au moyen du SDK Guardian.

​

Remarques

• La valeur login_hint respecte le format iss_sub. Par exemple :

{ "format": "iss_sub", "iss": "https://[TENANT_DOMAIN]/", "sub": "auth0|[USER ID]" }

• L’authentification peut se faire à l’aide du Client Secret (par authentification Basic HTTP ou Post), de Private Key JWT ou de mTLS. Veuillez consulter les exemples détaillés ci-dessus.

​

Paramètres du corps de la requête

client_id · string · requis

Le client_id de votre application.

binding_message · string · requis

Une chaîne lisible par l’utilisateur lui permettant de s’assurer qu’il approuve la bonne requête.

login_hint · string · requis

Un objet JSON contenant les détails de l’utilisateur aux fins de l’authentification, au format iss_sub.

scope · string · requis

Liste de portées OIDC et d’API personnalisées séparées par des espaces, comprenant au minimum openid.

audience · string

Identifiant unique facultatif de l’API cible pour les jetons d’accès.

resource · string

L’identifiant de l’API cible (serveur de ressources) à laquelle vous voulez accéder. Il doit correspondre à un identifiant d’API enregistré dans votre tenant Auth0. Ce paramètre sert d’alternative à audience lorsque le profil de compatibilité du paramètre de ressource du tenant est défini à compatibility.

requested_expiry · string

Délai d’expiration personnalisé de la requête, en secondes (1 à 300). La valeur par défaut est de 300 secondes.

authorization_details · array

Tableau JSON facultatif d’objets décrivant les permissions à autoriser. La valeur type de chaque objet doit avoir été enregistrée au préalable sur le serveur de ressources au moyen du paramètre authorization_details de celui-ci. Pour en savoir plus, consultez la documentation de la Management API Mettre à jour un serveur de ressources.

​

Messages de réponse

Statut	Description
200	La requête d’authentification a été lancée avec succès.
400	Requête incorrecte - paramètres invalides
500	Erreur interne du serveur