CIBA, like other OpenID Connect profiles, is fundamentally about authenticating users and authorizing clients. However, unlike many other OpenID Connect authentication flows, this one affords relying parties much more flexibility in how they go about doing it compared to more familiar OIDC flows. CIBA also introduces a couple of new concepts as part of this flow. 

The first concept is authentication devices. As we can infer from their namesake, authentication devices are “the device on which the user will authenticate and authorize the request, often a smartphone¹.” We can imagine using our phones to respond to a push request through an authenticator app, or via a legacy SMS or voice channel. In either case, the phone is the device we will use for authentication.

The other concept CIBA introduces is that of consumption devices. Consumption devices are intermediary devices that facilitate the consumption of a service. The specification is careful to highlight that a consumption device might not be under the user’s control (unlike the authentication device), but is simply a device that aids consumption of a service. The relying party may control the consumption device. That device could be sophisticated enough to operate its own client, or be a more simplistic interface, such as a gas pump, or a credit card payment terminal at a shop. In these situations the consumption device would be the terminal accepting your payment information. Consumption devices are not required to be technologically limited; they may have sufficient compute capabilities as to house or control the relying party’s client. Consumption devices, in conjunction with authentication devices, are what opens new opportunities for secure user authentication in some interesting, new contexts. 

There is one more unique characteristic of CIBA that needs explaining. Unlike the traditional browser or app-based flow like the authorization code flow, CIBA doesn’t use redirects between the relying party and offering party in the user’s browser. In fact, there may not be any browser to speak of in a CIBA flow. Using the gas pump example, a user could be authenticated in order to raise the assurance at the point of sale, all from the gas pump (the consumption device) triggering a push to the user’s phone (the authentication device). Setting aside the UX improvements the authentication push can offer, authenticating the person interacting with the pump prior to taking payment represents a significant enhancement for both the security and assurance of that transaction. 

CIBA can perform this redirect-free authentication flow in one of three methods: poll, push, or ping modes. Given the simplicity of each of these flows, much of the information below is taken from the CIBA specification document².

In poll mode, the client will poll the offering party’s token endpoint at intervals and wait for information on the status of the authentication event to appear in the response.

Under the push mode, the offering party pushes (or more accurately, POSTs) the result of the authentication event to the client once it has an authentication response.

Finally, under ping mode, the offering party will post the unique identifier of the authentication session to the client. The client then retrieves the authentication result from the offering party’s token endpoint. 

Though these three methods vary slightly in how they handle authentication, they are all designed to offer comparable user experiences in environments where authentication is necessary or desired, but a typical browser-based experience may not be feasible. These methods allow relying parties to offer improved user experiences by keeping them at their own site, or by offering  interaction through a consumption device, all while raising the confidence and security of the transaction.

For more information on using the CIBA flows in your applications, check out the full specification on the OpenID Foundation website.

1. https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.2
2. https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.5

Jon Lehtinen

Director of Okta on Okta at Okta, Board Member IDPro

Jon Lehtinen has 16 years of enterprise identity and access management experience, and specializes in both the strategy and execution of Identity & Access Management transformation in global-scale organizations like Thomson Reuters, General Electric, & Apollo Education Group. He works to deliver automated, future-oriented Identity solutions that provide the bedrock for information security, governance, and new opportunities for business. Moreover, Jon is dedicated to the growth and maturity of IAM as a profession, and serves on the Board of Directors and Treasurer of IDPro.org. He’s a member of the Kantara Initiative, ISC2, OpenID Foundation, and Women in Identity, served as an advisor to EvidentID, and a published author.

Jon has presented on his work at several conferences, including RSA, Identiverse, and KuppingerCole’s European Identity & Cloud Conference. He currently owns the workforce and customer identity implementations at Okta as their Director of Okta on Okta.

            

The post Client-Initiated Back Channel Authentication Finalized appeared first on IDPro.