Separating the consumption and authentication devices

A kiosk you do not own

The kiosk asks for the email address of your photo account, and you type [email protected]. A moment later your phone shows a notification from the photo service: Print kiosk wants to sign you in and view your photos. You open it, check the details, and approve with your fingerprint. The kiosk's screen changes to show your albums.

Nothing passed through a browser on the kiosk. There was no redirect to the photo service and no sign-in page on the touchscreen. The kiosk sent its request straight to the photo service, server to server, and the photo service contacted you on your phone. This is Client-Initiated Backchannel Authentication, usually shortened to CIBA. It is an OpenID Connect specification. The client starts the authentication, the provider carries it out somewhere else, and the client receives an ID token saying who approved, together with an access token for the access it asked for.

"Backchannel" describes the route. Every sign-in so far used the browser as a front channel, carrying requests and responses between the relying party and the provider in redirects. Here the client and the provider talk directly, and the person is reached separately, on another device.

The kiosk is a registered client of the photo service, with the client ID printer-kiosk. The printing company runs it, and the kiosk's software works through the company's servers, which hold the client's credentials. The screen in the shop never holds them, so the kiosk can be a confidential client even though it stands in a public place. That matters, because CIBA expects the client to authenticate whenever it asks for a sign-in, as Following a CIBA exchange shows.

Two devices, two jobs

CIBA names the two devices by what you do with them. The consumption device is where you use the service, here the kiosk. The authentication device is where you sign in and approve, usually your phone. The specification is direct about one property of the consumption device: you are not necessarily in control of it. It may belong to the client, like the kiosk, or sit in front of the client's staff.

The examples the specification gives all share that shape. A call center agent wants to confirm that a caller really is the account holder. A bank teller wants a customer at the counter to approve something on their own phone. A shopper approves, on their phone, a payment they are making at a checkout terminal. In each case the device the service runs on belongs to someone else, and the place where the person can safely prove who they are is a device they already carry.

The split decides what each party handles:

How the photo service reaches your phone is its own choice. The specification only requires that it has some way to start an authentication out of band, away from the kiosk. A notification to its own app, where you are already signed in, is the usual answer. However it reaches you, once you are authenticated the photo service asks for your decision just as its consent screen would during an ordinary sign-in.

When you finish printing, the kiosk has to forget you. It ends its session and discards the tokens it received, and it has no reason to ask for offline_access or keep a refresh token. The next customer should find no trace of your account.

Compared with device authorization

The photo frame in Device authorization also split the work between two devices, so the two flows are easy to confuse. The difference is who goes to whom.

With the photo frame, you started on the frame, read a code from its screen, and went to the photo service yourself, in your phone's browser, to type the code and approve. The frame never needed to know who you were. With the kiosk, you tell the kiosk who you are, and the kiosk asks the photo service to come to you. You never visit a verification page or type anything from the kiosk's screen. The request arrives on a device the photo service already knows is yours.

Each design's weak point follows from this. The risk with device authorization, as that lesson showed, is a code someone else started: an attacker sends you a code and a genuine link and hopes you approve. CIBA turns that around. The attacker does not have to send you anything, because the request arrives from the photo service itself, in its own app. Anyone at a kiosk can type your email address, and your phone will show a genuine request. Binding the authentication to the request covers the defenses CIBA provides.

The choice between them comes down to what the client can know. CIBA fits when the person has a trusted device with them but the screen in front of them is not theirs, and the client can learn who they are. Device authorization fits a device that nobody identifies in advance, such as a television in a living room, because it needs no hint at all. And when the device in front of you is your own and can open a browser, the authorization code flow keeps the sign-in and its result in one place.