Everybody wins with the Device Flow

Have you ever heard of the device flow, or the OAuth 2.0 Device Authorization Grant? If not, make sure you keep reading, as the device flow is pretty awesome to support an ever-growing group of applications. If you already know about the device flow, you should skip to the second half of the article, where we discuss the details and the surprising amount of security benefits.

18 August 2020 OAuth 2.0 & OpenID Connect OAuth 2.0, OIDC, Authentication

Running OAuth 2.0 and OpenID Connect on devices

Internet-connected devices running applications are everywhere nowadays. Traditional examples are game consoles, TV boxes, and media centers. More unconventional examples are smart fridges or fancy audio speakers that allow live streaming from the Internet. Of course, you also have kiosk systems in stores and restaurants, billboards, etc. There are plenty of examples, but these systems typically have two things in common:

1. They have a hard time handling complex user input, such as credentials
2. Many of them do not have the ability to run a system browser

Let’s look at a straightforward example from my personal life. At home, we have an Apple TV, used daily to stream everyone’s favorite show: Paw Patrol. The first time you open Netflix, you need to authenticate with your Netflix username and password. Pretty straightforward, right. That is until you get to enter the password, which is randomly generated by Dashlane, my password manager (contact me if you want a referral bonus). So authenticating to Netflix means pulling out another device, opening Dashlane, looking for the password, and spending the next 5 minutes swapping between different character sets on an on-screen keyboard.

I used Netflix as an example here, but these scenarios are everywhere. The Apple TV does not support running an OAuth 2.0 flow in a browser, so Netflix has almost no alternative to handle user authentication than to ask for credentials directly. At least these devices have a way to request user input, albeit somewhat awkwardly. Some devices, such as kiosk systems or smart speakers, have no input capabilities, making it even more difficult for users to log in to an app.

That’s where the OAuth 2.0 device flow comes into the picture. Before we dive into the details, let’s take a look at what the device flow can do.

Improving the user experience

You can’t watch Paw Patrol all day long, so the next best thing is listening to the theme song with Spotify. Again, opening Spotify on an Apple TV requires you to sign in with your Spotify account. However, instead of asking for a username and password, Spotify sends the user to the Spotify website with a unique code.

When a user opens this website on a phone or computer, the user is asked to authenticate with a username and password. The main difference is that the user is now authenticating in a regular browser. This means that the user can rely on stored passwords or password managers if desired.

After authentication, the Spotify application on the Apple TV is linked to the user’s account, and the music starts playing. This magical user experience is driven by the OAuth 2.0 device flow. Let’s take a look behind the curtain.

The details of the OAuth 2.0 Device Flow

Now that we know what the device flow looks like from the user’s perspective, it’s time to dive into the details. The image below shows each of the steps in the device flow. Let’s walk through the flow step by step.

Once the user indicates they want to authenticate to the application (e.g., Spotify running on an Apple TV), the client will initiate the flow (Step 1). The client sends a request to the Security Token Service and includes the client ID in the request’s body. If desired, the client can also add a scope.

If everything checks out, the Security Token Service responds with a URL, a user code, and a device code (Step 2). This URL will take the user to the authentication page of the Security Token Service, where the user is expected to enter the code. The client renders this URL and code on a screen (Step 3A). The exact mechanism for displaying this data is up to the client. Typical examples are static text or a scannable QR code.

Once the client started showing the data to the user, the client begins polling the Security Token Service for the result using the received device code (Step 3B). With this device code, the Security Token Service can lookup the active flow and inspect its current status. The Security Token Service informs the client of that status.

While the client is polling, the user will complete the flow on their device. This involves authenticating as a user (unless a session already exists) and optionally giving the client consent to access their data (Steps 4 - 8).

In the meantime, the client is still polling the Security Token Service (Step 3B). After the user has completed the flow, the Security Token Service will send the proper response to the client (Step 9). That response typically includes an access token, and optionally a refresh token and identity token.

With the information in the identity token, the client application can welcome the user (Step 10). With the access token, the client can access APIs on behalf of the user (Step 11 and 12). In our Spotify example, the client can use the access token to retrieve the user’s music and start streaming audio.

Benefits of the device flow

The use of the OAuth 2.0 device flow instead of on-device authentication has quite a few advantages. Let’s summarize them:

1. The user does not have to enter passwords with clunky on-screen keyboards
2. The application can use OAuth 2.0, even when there is no system browser available
3. The user can follow their standard authentication procedure, including the use of stored passwords and password managers
4. The authentication can rely on advanced authentication mechanisms, such as WebAuthN and USB security keys
5. The entire user experience is more secure in case the device running the app is untrusted

The last item on this list is pretty interesting. Why would a user want to authenticate on an untrusted device?

Again, a story from my personal life. In pre-pandemic times, I traveled the world to teach developers how to build secure applications. That meant spending a significant amount of time in hotels, which nowadays, almost all have smart TVs. You can watch Netflix with your account on the hotel TV (gotta get that Paw Patrol fix!). Of course, this means signing in with your Netflix account.

The thing is, I don’t trust “smart” devices, especially smart devices I have zero control over. I am not keen on entering my actual credentials on the hotel TV. Even though those credentials are only valid for Netflix. It just feels dirty. So, one takeaway here is that I significantly underuse TVs in hotel rooms.

However, the more important takeaway is that Netflix should start using the OAuth 2.0 device flow. With the OAuth 2.0 device flow, I never have to give my credentials to an untrusted device. Instead, I sign in on the Netflix website on my device, after which the app on the untrusted TV receives tokens to access my account. The untrusted device still has access to Netflix in my name but does not have my account credentials.

Additionally, when I leave the hotel, I can log in to my Netflix account and revoke the refresh token for that smart TV. That way, I can ensure that the next guest will not inadvertently gain access to my Netflix account.

Summary

Here’s a five-word summary: The device flow is awesome.

A more extended version would state that the device flow offers a superior UX compared to on-device authentication. It enhances the authentication process by allowing users to rely on security features such as password managers and MFA. Additionally, the device flow avoids exposing credentials to untrusted devices and allows more control through token revocation.

Finally, if you want to learn more about using OAuth 2.0 and OpenID Connect to secure applications, check out my online course on this topic. The course transforms literally dozens of specifications into actionable guidelines and advice.