The possibilities of OAuth 2.0 Device Flow
Device flow or more formerly device authorization grant is one the latest extension grants introduced to OAuth 2.0 through RFC 8628 (OAuth 2.0 Device Authorization Grant). It is was introduced to make the life of users easy when sign-in into input constrained devices. So what does that mean?
Take a smart tv that has Netflix in it, now you want login to your Netflix account. Typing the email and password should be fun with the remote controller?
Isn’t there an easier way to do this? There is! if you can see that “Sign in from Web” button if that was clicked something like below would show up on screen.
You can either directly visit https://www.netflix.com/tv8 or scan the QR (both leads to the same place) from your phone(or any other device with a web browser) and login by typing the email and password from the comfort of your phones QWERTY keyboard or better yet if your already logged in from the phone you only need to add that code.
So this is what device flow does, it provides an easier way to do authorization for input constrained devices. Lets look at how the flow works.
The client calls the /device_authorization endpoint of the authorization server and the server responds with a Device Code, User Coder, and a Verification URI.
Then the client needs to communicate to the end user in some manner the Verification URI and the User Code. The verification uri is the one used by the user to navigate to the login page through a different device. If we take the above smart tv Netflix example, https://www.netflix.com/tv8 is the verification uri. The client also needs to convey the User Code to the user and ask to enter it in the page visited from the verification uri.
While the user is performing the authorization in a second device the client should poll the /token endpoint of the Authorization Server using the provided Device Code and Client Identifier. During some point in polling, once the user has authorized the client, the client will receive the access token as the response to the polling request.
The above smart tv example is the most basic thing you can do with device flow. Let’s see what else is possible.
The possibilities of device flow
The smart tv is sort of an obvious use case for device flow. Many applications such as Netflix, Youtube, Apple Music, Amazon Prime uses this flow in their smart tv apps. In the above smart tv example the verification url and the user code is displayed to the user. In the device flow specification it doesn’t necessary say that these should be “displayed” to the user but communicated to the user in some manner. It could be via displaying in a screen, via NFC(Near-field communication) or BLE(Bluetooth Low Energy), reading it out using a speaker or any other means of effective communication (but make sure its a close proximity communication). Now this opens up several other possibilities with device flow.
IoT Devices
Another obvious usage for device flow would be IoT devices. If there is some device that a user needs to login and the device has someway of communicating with the user then the user can directly authenticate to the device with the use of a mobile phone (any device which has a bowser actually). And there wouldn’t be a need to provide the credentials in any other place than the identity provider. Another example would be wearable tech such as smart watches and fitness trackers where a user would need to login to the device or an app in the device. If the wearable is having a display it could display a small QR code or if it has NFC of BLE it could transmit the login page url to the phone.
Command Line Tools
CLI tools are common now and are provided from many services (ex: Azure, Heroku, Firebase, etc) and these service generally need you to log in to the servicer through the CLI to be able to access the service. Now theres two options; one is using the password grant (or basic authentication). Whats wrong with using the password grant (or basic authentication) you may ask. Using the password grant is no longer a recommended industry best practise, you can read the reasons behind it from the (currently under development) OAuth 2.0 Security Best Current Practices document from here. It would be user friendly but you end up providing your credentials to the CLI. Do you really trust it to give your credential to a command line tool?. Also what if you need to have MFA or you want a federated login? So then we come to the second option which is using an Authorization Code grant (with PKCE) where the CLI will open a browser agent and you can directly login at the identity provider. Bit of a hassle flow for a dev to implement in a CLI and also what if there are no browsers in the machine? Then it will be a no go for the Authorization Code flow. Now here is another place where the OAuth2 device flow can be easily used. The CLI will simply display a url for the user to access from some device and login. This flow is currently used in the Azure CLI.
Virtual Reality Apps
Virtual Reality applications are gaining popularity especially with the metaverse. How can we login to a VR application? Could be quite hard navigating those controllers to type on a keyboard even harder than using your TV remote to login to a smart tv app. This is another place where OAuth2 device flow can be used, where the user can use another device to perform the authorization. The overall user experience would not be perfect as the user would be disconnected from the virtual experience momentarily but its a good start and we can see how the experience can be smoothen.
The bottom line is, if you have an input constrained device or a software that cannot access a browser agent which needs a user to do some authorization and that device/software has the capability to communicate with the user in an effective manner. Then the OAuth2 device flow can be used to easily create an authorization flow.
Wanna give device flow a try? OAuth2 Device Flow is supported in WSO2 Identity Server 6.0.0 onwards. To try it out download the latest WSO2 Identity Server from here and check the documentation here.
