Qu'est-ce que CIBA (Client-Initiated Backchannel Authentication) ?

CIBA en bref#

Dans les flux classiques d’OpenID Connect, l’utilisateur est devant l’application qui demande sa connexion : elle redirige son navigateur vers le fournisseur d’identité, il s’authentifie, puis revient.

CIBA (Client-Initiated Backchannel Authentication) couvre le cas où ce n’est pas possible : l’application qui a besoin de l’authentification n’est pas entre les mains de l’utilisateur, ou n’a pas de navigateur. Elle contacte directement le fournisseur, de serveur à serveur, en lui indiquant quel utilisateur doit être authentifié. Le fournisseur joint l’utilisateur sur un autre appareil, typiquement par une notification sur son téléphone, et l’utilisateur approuve ou refuse. L’application récupère ensuite les jetons.

Pas de redirection, pas de navigateur partagé : l’échange entre l’application et le fournisseur passe entièrement par le canal arrière (backchannel).

Des cas d’usage concrets#

• Un centre d’appels. Le conseiller doit vérifier l’identité de la cliente au téléphone. Plutôt que de lui poser des questions secrètes, son application déclenche une demande ; la cliente reçoit une notification et l’approuve sur son téléphone.
• Un terminal de paiement ou une borne. L’utilisateur saisit un identifiant sur la borne et confirme sur son propre appareil, sans taper de mot de passe sur un équipement public.
• La validation d’une opération sensible. Un virement initié depuis un poste de travail est confirmé sur le téléphone du titulaire.

CIBA distingue deux appareils : l’appareil de consommation (Consumption Device), où le service est utilisé, et l’appareil d’authentification (Authentication Device), où l’utilisateur prouve son identité et donne son accord.

Comment ça marche#

La demande initiale identifie l’utilisateur par un indice : la norme en prévoit trois, dont exactement un doit être fourni.

D’autres paramètres complètent la demande : scope, qui doit contenir openid ; acr_values, le niveau d’authentification souhaité ; binding_message, un court texte affiché à la fois sur l’appareil de consommation et sur le téléphone, pour que l’utilisateur sache qu’il approuve bien la bonne opération ; requested_expiry, la durée de validité souhaitée.

Le fournisseur répond immédiatement, sans attendre l’utilisateur :

{
  "auth_req_id": "1c266114-a1be-4252-8ad1-04986c5b9ac1",
  "expires_in": 300,
  "interval": 5
}

L’application obtient ensuite les jetons à l’endpoint de jeton, avec le grant urn:openid:params:grant-type:ciba et l’auth_req_id.

Trois modes de livraison#

Le client choisit, lors de son enregistrement, comment il apprendra la décision de l’utilisateur.

Les modes ping et push reposent sur le paramètre client_notification_token, que le fournisseur présente au client pour s’authentifier lors de l’appel. Le mode push est le plus délicat à sécuriser, et le profil FAPI-CIBA l’exclut.

Bonnes pratiques#

• Affichez toujours un binding_message explicite, par exemple « Virement de 250 € vers M. Martin », et le même texte des deux côtés. Sans lui, un utilisateur peut approuver une demande qui ne vient pas de lui.
• Ne déclenchez une demande qu’après une action volontaire de l’utilisateur. Des notifications répétées finissent par être approuvées par lassitude.
• Respectez l’interval renvoyé par le fournisseur et arrêtez d’interroger à l’expiration de la demande.
• Signez les demandes d’authentification (paramètre request) : le fournisseur a ainsi la preuve que la demande vient bien du client et n’a pas été modifiée.
• Réservez CIBA aux clients confidentiels, capables de s’authentifier auprès du fournisseur.

CIBA dans TOSIAM#

TOSIAM implémente CIBA en mode poll. L’endpoint d’authentification est l’adresse de l’émetteur suivie de /bc-authorize, par exemple https://login.example.fr/tosiam/oauth2/clients/bc-authorize. Il n’accepte que des requêtes POST au format formulaire.

Une demande signée obligatoire. TOSIAM authentifie le client, puis exige que la demande soit transmise dans un request object signé, le paramètre request. La signature est vérifiée avec les clés publiques déclarées pour le client. TOSIAM contrôle aussi que l’émetteur (iss) du JWT est le client lui-même, que la demande n’est pas expirée (exp), que le scope contient openid et qu’exactement un des trois indices est présent. L’utilisateur est identifié à partir de login_hint.

L’authentification de l’utilisateur. La valeur acr_values de la demande est recherchée dans la table « Correspondance acr_values OpenID Connect vers chaînes d’authentification » du fournisseur OAuth2, qui la relie à un service d’authentification. Indiquez donc toujours une valeur présente dans cette table : sans elle, aucune authentification n’est déclenchée. TOSIAM exécute ce service côté serveur, en arrière-plan, et lui transmet le login_hint comme identifiant. Le service choisi doit donc pouvoir joindre l’utilisateur sans navigateur, par exemple par une notification push à laquelle il répond sur son téléphone. Selon l’issue, la demande passe à l’état approuvé ou refusé.

La récupération des jetons. Le client interroge l’endpoint de jeton avec le grant urn:openid:params:grant-type:ciba. Ce grant doit figurer dans la liste des grants autorisés du client, et le client doit être confidentiel. TOSIAM répond authorization_pending tant que l’utilisateur n’a pas répondu, slow_down si le client interroge plus vite que l’intervalle annoncé, expired_token après expiration et authorization_declined en cas de refus. Un auth_req_id ne sert qu’une fois : il est consommé dès la délivrance des jetons, qui comprennent un refresh token si le fournisseur en émet.

Les réglages. Deux réglages du fournisseur OAuth2 encadrent les demandes : la durée de vie d’une demande, 300 secondes par défaut, et l’intervalle minimal entre deux interrogations, 5 secondes par défaut. Les demandes en attente sont conservées dans le Core Token Store.

Pour aller plus loin#

• OpenID Connect CIBA Core 1.0, la spécification de référence
• FAPI: Client Initiated Backchannel Authentication Profile, le profil de sécurité pour les usages financiers
• OpenID Connect Core 1.0