/images/resources/architect/openid-connect/ciba-vs-device-flow/curity-article-device-flow.png

Device Flow vs CIBA | Which Flow Should You Choose?

On this page

Both the OAuth 2.0 Device Authorization Grant (RFC 8628) and the OpenID Foundation Client Initiated Back-Channel Authentication (CIBA) are targeting scenarios where the authentication steps are decoupled from the rest of the flow. At the surface these two flows might seem identical but there are some distinct differences. Let's take a deeper look at what sets them apart.

Neither of these two flows should be used for scenarios when the device initiating the authorization is the same as the device used for authorization. That should instead be handled by the OAuth Code Flow. If it's a non-user involved scenario where the use case involves server-to-server communication the Client Credentials Flow is more appropriate.

OAuth 2.0 Device Authorization Grant

The Device Authorization Grant, also known as the Device Flow decouples user authentication from the device that is requesting to obtain an access token, the initiating device. The primary use is for devices where it is difficult to enter credentials to perform use authentication. This approach is very commonly used with apps running on a TV or set-top-box.

Token(s) issued after successful user authentication

The user typically selects a provider and is presented with a URL + code and/or a QR code to scan. The QR code approach is a convenience and does the exact same thing as the URL + code in the end. Instead of authenticating directly on the TV app, the user enters the URL (or scans the QR code) on a different device that is better suited for authentication, e.g. a laptop or a phone. This redirects the user to the authentication mechanism configured where the user can authenticate. This is still very commonly a username and password but passwordless options are gaining traction.

The initiating device polls the authorization server to check if the user has authenticated. The response from the authorization server is going to be 400 authorization_pending until the user has successfully authenticated on the separate device.

Poll the token endpoint

When the user has successfully authenticated out of band, the response from the authorization server are tokens that the initiating device can use to gain access to APIs.

Token(s) issued after successful user authentication

An advantage with the Device Flow is the broad usability across different devices as the protocol doesn't have any specific requirements on the authenticating device itself.

OpenID Connect Client-Initiated Backchannel Authentication

OpenID Connect Client-Initiated Backchannel Authentication, or CIBA for short, is also a decoupled flow. The flow allows a device or service to initiate the flow with the authorization server when the user is known. A significant difference between CIBA and the Device Flow is that the user does not scan a QR code or enter a URL + code to initiate authentication in the case of CIBA. Instead, the authorization server "pushes" the authentication to the user through email, SMS or another mechanism such as a mobile app.

The device that authentication is pushed to, needs to be registered for the user for the authorization server to trigger authentication on the correct device. That is straight forward when it comes to email or SMS as the email or phone number is typically unique and associated with the user. If another mechanism is used to push the authentication to the user, such as BankID or other apps, the authorization server needs to know what device to push authentication to.

The flow is still decoupled in the sense that the Client, also known as the Consumption Device, obtains the access token directly from the authorization server. But the authentication takes place on a separate device by the user.

Client Initiated Backchannel Authentication

A great example of use for CIBA is to authenticate customers that are calling in to a call center. They can provide an identifier and the customer service representative initiates the authentication on their end (client / consumption device). The user is prompted to authenticate on their authentication device and the customer representative can determine that the user is who they say they are. No need to use insecure or cumbersome questions such as first car, favorite color or mother’s maiden name.

Conclusion

Neither CIBA nor Device Flow should be used for scenarios where the initiating device is the same as the device the user authenticates on. Prefer CIBA of the Device Flow but know that a requirement is that a user identifier needs to be known for the CIBA flow to be initiated. If this is not possible (e.g. the previous example of TV or set-top box), use the Device Flow.

Device FlowCIBA
SpecOAuthOIDC
Requires UserYesYes
Preregistered UserNoYes
Example Use CaseTV apps, cars or otherwise input constrained devicesAuthenticate at a call-center, Point of Sale (POS) terminals
Photo of Jonas Iggbom

Jonas Iggbom

Director of Sales Engineering at Curity

Join our Newsletter

Get the latest on identity management, API Security and authentication straight to your inbox.

Start Free Trial

Try the Curity Identity Server for Free. Get up and running in 10 minutes.

Start Free Trial