A Brand New Client Initiated Back-channel Decoupled Authentication

Episode 01: Basic Understanding of Client Initiated Back-channel Authentication)

Breakup(DE-COUPLE) Photo by Kelly Sikkema on Unsplash

Jarvis???

Sir! How Can I Help You?

My Colleagues have come a long way searching for the note on CIBA. I am busy with the brief on ‘This Is How You Lose Her’.

Oh, Sir!! That’s about love and the breakup by Junot Diaz. By the way, CIBA too is a kind of breakup.

What??

CIBA basically eases the decoupling of Authentication device from Consumption device.

Hold on Jarvis!!! We need briefing and ground examples. Can you?

Client-Initiated Back Channel Authentication

“Hi, People. As a person who is interested in CIBA(Client-Initiated Back-channel Authentication), I, Jarvis desired to explain CIBA to my fellow associates and evangelizing people, especially co-developers of enterprise systems to exploit it for the greater good.

As it is briefed in the name itself, an authentication request is made by the client application. But what’s the major difference from traditional flows is here is, the client initiates a back-channel authentication flow. In traditional flows, the request is made by the client via browser hence which we will name as “Front Channel Authentication flow”. Oh oh.!!

Well, it might be intriguing too. Let’s keep it simple. But to have an adequate perception of the scenario, it is mandatory that we are familiar to the terminology of CIBA, at least for these below.

• Authentication device: Used by the end-user to authenticate himself to the Authorization Server.
• Consumption device: The device that is engineered for end-users to receive services.

The Love :

In most enterprise systems, both these authentication and consumption devices are packed into one, “Two souls into one body”.They are in love — coupled.

Fig.1. Coupled Authentication and Consumption Devices and the Abstracted Communication flow

Say, Bob owns an app “Payhere”, the service.

• Alice downloads the app on to his Android/IOS phone. Then he registers himself for the service.
• Then he logs into the app using his credentials. He also will annex his credit card details here with the app.
• Now he wants to pay the electricity bill. He gets into the app. Choose “Pays Electricity Bill” option.
• The app will challenge Alice by requesting to authenticate himself (SMTP); ie app will send him a message with 4 digit code to use and authenticate that request is exactly made by him.
• Alice will enter the number and authenticate (Multifactor authentication)
• Upon correct authentication, service will be provided.

This is the most popular, abstracted scenario out there. Here Both authentication and consumption device is the phone itself- coupled.

The BreakUp :

But technology matures. People never contended. And there emerges a demand for decoupling(breakup) the authentication device from consumption device.

Let’s consider the scenario.

Fig.3. CIBA flow

Bob is a member of “The Solitude Club ”, the club where people with loneliness and solitude, meet and also accompanied by a trusted person talk to. And Bob is a proud premium member of the club.

• Bob is provided with a membership card (NFC tagged). It is mandatory that Bob takes a membership card along with him. And at the entrance, Bob has to tap it against the “CardReader system” (Consumption Device).
• Note that Bob has to download an app (SolituderIdentity app). Bob has already logged into the app using your email and password and credit card details are annexed, so that amount for the day can be directly deducted from his bank.
• Now when his card is tapped against the system(Client), the system initiates a request to the Authorization Server(WSO2 Identity Server).
• Authorization server, upon receiving the request to initiate the transaction, wants the end-user to authenticate the transaction. So Authorization Server requests Bob to authenticate the transaction. So it sends an authentication request.
• Upon seeing the request on his app on his phone(Authentication Device), Bob authenticates the request(ensure that transaction is initiated by himself)and approves(authenticates) the transaction (using SmsOTP).
• Upon receiving the authentication and the consent, authorization server admits the client(consumption device) to initiate the transaction with the bank by passing down access and identity token.
• The client initiates the transaction and a happy customer.

Pretty Cool.!!!

This is the outline of CIBA. It eases out decoupling of authentication device from a consumption device. It is still an infant, but super cool.

WSO2 Identity server still hasn’t provided support CIBA yet. But they will be keen on extending support for this pretty cool stuff.

CIBA is so Cool, because no such annoying redirections and highly secured as no such browser redirections involved.

Following is the sample authentication flow for CIBA.

Fig.4. Ciba Abstract Flow

There are various kinds of flows after consent confirmation. Anticipate Vivek will blog them vividly.

Signs off Jarvis!.

Sir? Do you still think that love can hold you from your passion? Breakup faster for the greater good !! CIBA supports De-Coupling !!!! Hahaha.

Yes.Thanks, Jarvis.Will surely consider. Lol.

We will drive beside the technical environment in a short while. Meeting you sooner !!!. Jarvis doesn’t go to sleep. You have to decode CIBA further for the next blog……..