Nowadays, access management and security concept of APIs are inherent to federation protocols OAuth2 and OpenID Connect. Both protocols natively cover a great deal of use cases, but regularly evolve and come with complements to address more innovative subjects.
In particular, with the explosion of the IoT and regulations such as DSP2, the need to trigger uncorrelated authentications from the user’s medium access become more pressing: indeed, the later may not have the necessary interfaces, or may not be recognized as a sufficiently secured support.
The additional cinematic CIBA, Client Initiated Backchannel Authentication Flow aims to define the exchanges and calls allowing to trigger such authentications. This first article aims to briefly describe the high-level operation of this cinematic, and to present the contributions and additional use cases that it can cover.
What is CIBA?
CIBA is a new authentication flow and authorization of the OpenID Connect standard, defined by the Open ID foundation.
The CIBA flow is the first OpenID flow qualified as ‘’decoupled’’, because it introduces the notions of Consumption Device (CD) and Authentication Device (AD). The CD is the device on which the access to a service (Relying Party, RP) is requested, whereas the AD is the device on which the user authenticates themselves with the OpenID Provider (OP) and authorizes the CD-requested access, by giving its consent.
Contrary to the other flows of the OIDC standard, CIBA considers that the user can authenticate on a device different from the one on which he wants to access the service. For example, a user is looking to access his bank account from his computer and authenticate themselves to authorize the access from his smartphone.
What contributions?
The CIBA flow presents several significant interests for users’ authentication.
Today’s OIDC authentications flows are relying on web redirection between the accessed service (Relying Party) and the identity provider. These redirections are not very user-friendly and might be disturbing for the users, who see their browser, or their application go from a page to another without really understanding this behaviour. With CIBA, the device that the user employs to access the service stays on said service’s page, waiting for user authentications to be executed on the AD. The redirections’ disappearance also improves the Relying Party’s acceptance, which does not lose control and visibility of the user’s action when the latter must authenticate themself to the OP anymore.
Gains by population
The multi-factor authentication (MFA) is more and more common and recommended to access internet services. Texts, soft-tokens or Out-Of-Band push notifications are several examples of additional authentication factors, used today in addition to a password. With CIBA, this factor’s presence is a natural part of the authentication, since it is carried out on a registered device like AD. Asking the users to authenticate themself on the AD with a password, a PIN, a biometric factor, etc… allows a centralization of the authentication actions on a single device, while allowing to do some MFA.
Use case examples
The call centre
Nowadays, when a client rings a call centre, the operator often verifies the client’s identity with several personal inquiries (date and place of birth, social security number) or with security inquiries. This authentication method is particularly vulnerable to attacks, such as social engineering.
Thanks to CIBA, it is possible for the operator to trigger an authentication request for callers on their Authentication Device, and thus ascertain the client’s identity in a more secure fashion.
Virtual assistants
DSP2 imposes banking organisations to ascertain the identity of the person carrying out an operation over a certain threshold, which mandatorily passes through an authentication phase (2 factors) during a transfer, for example. However, IoT such as the voice assistants do not have an interface allowing the user to input their identifiers, and force the customer to validate a transfer request on a web portal via his smartphone or his PC, which is not the ideal user experience. CIBA is used to free oneself from this constraint, because the customer’s bank is then able to send an authentication request on the adequate terminal (AD), limiting the impression of a break in course for the customer.
Conclusion
The authentications cinematic CIBA fills real weaknesses of the OpenID Connect protocol, both in terms of functional coverage and customer experience. It’s implementation in the real world should happen quickly, and numerous market players are already looking to implement it.
