OAuth 2.0 Device Authorization Grant

  • The device is already connected to the Internet.
  • The device is able to make outbound HTTPS requests.
  • The device is able to display or otherwise communicate a URI and code sequence to the user.
  • The user has a secondary device (e.g., personal computer or smartphone) from which they can process the request.

Youtube Example

Let’s look at one common example in our lives. At home, most of us have a smart TV and want to stream something. In this example we want to stream video from YouTube. The first time you open YouTube, you need to authenticate with your username and password. The problem begins when you need to enter your password and you spend a lot of time swapping between different character sets on an on-screen keyboard, probably making a mistake in the process. I used YouTube as an example here, but these scenarios are everywhere.

Device Authorization Flow

Now that we know what the device flow looks like from the user’s perspective, let’s dive into the details. The image below shows each of the steps in the device flow.

Security Considerations

1. User Code Brute Forcing

Since the user code is typed by the user, shorter codes are more desirable for usability reasons. The user code should have enough entropy that, when combined with rate-limiting and other mitigations, a brute-force attack becomes infeasible.

2. Device Code Brute Forcing

As the device code is not visible to the user, a very high entropy code should be used.

3. Remote Phishing

Sometimes an attacker might send an email instructing the target user to visit the verification URL and enter the user code. To mitigate such an attack, it is recommended to inform the user that they are authorizing a device during the user-interaction step and to confirm that the device is in their possession.

4. Non-Confidential Clients

Device clients are generally incapable of maintaining the confidentiality of their credentials, as users in possession of the device can reverse-engineer it and extract the credentials. Therefore, unless additional measures are taken, they should be treated as public clients which are susceptible to impersonation.

5. Non-Visual Code Transmission

There is no requirement to always display the user code to the user. It is recommended that to use any chosen communication channel only be accessible by people in close proximity, for example, users who can see or hear the device.

Conclusion

In this article we talked about internet-connected devices that are input-constrained and lack a browser. We saw the challenges that these devices present to developers and customers alike, and how you can use the Device Flow to tackle those challenges.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store