Solution guides

Device Flow: Access Control for Devices

In a system, where devices are used for access to services and APIs, businesses must ensure appropriate security measures and as much optimal user experience as possible for the end users. Learn how Cloudentity helps organizations to tackle the challenge of Authorization for Devices.

The Challenge of Access Management for Devices

Everyday, end users use all kinds of devices to access different kind of services. Sometimes, the device itself can lack appropriate input capabilities or does not have a browser installed making it difficult for the end user to authorize a device requesting access to their personal information. Such devices can include smart TVs or watches, printers, scanners, and more. Your organization may be a video streaming platform, printer supplier, or maybe it delivers watches that allow the end users to track their fitness or location. It does not matter as the challenge stays the same: How to deliver optimal user experience and ensure appropriate security level to protect your customers data when devices do not have a browser and/or the hardware is input constrained?

Organizations offering services using the abovementioned devices always face the challenge of authenticating the service. Traditional OAuth flows are not a good fit for the scenario as they would degrade the user experience with the service. The organization, instead, can allow the users to authorize the access request on a secondary device the user has access to. Such practice is a part of the OAuth 2.0 Device Authorization Grant (formerly known as the Device Flow).

Device Flow

Let’s consider the following scenario: an online streaming platform allows the users to log in to their service using software installed on a smart TV. In such cases, the primary device (the smart TV) initiates the Device Flow by providing the user with a verification URI and a user code. Very often for user’s convenience, the device provides also a QR code the user can scan. Now, the user can either scan the QR code or visit the verification URI manually (both using the smartphone) where they are able to provide the user code to confirm the device access.

After providing the user code, user is prompted to provide authentication to platform (in case the user is not already logged in). Depending on whether the service is configured to get user authorization consent, the user is prompted accordingly. After authenticating, the user can review the authorization (consent screen). They can accept or deny the device’s request for access and based on their decision the device receive security tokens or not. For the detailed information on how the flow takes place, see the OAuth 2.0 Device Authorization Grant (Flow) Authorization Basics article.

Such flow places the following challange on the organization:

  1. The organization must implement an authorization server capable of utilizing the OAuth 2.0 Device Authorization Grant (Device Flow).

    • The server must be able to generate (and later on verify) unique device- and user verification codes as well as verification URIs and include them in the HTTP response body of a Device Authorization API.

      Device codes are part of the device’s metadata and are used to verify the device requesting access to resources. User codes verify the user.

      The verification URIs are used to allow the user to review the authorization on a secondary device. The user can enter such URI on their secondary device’s browser and provide their user code. Since it cannot be copied between different devices, it must be short and easy to remember.

    • The authorization server must allow devices to register their OAuth client applications to enable devices to communicate with the authorization server using OAuth protocol.

      To make it possible to distinguish different devices and verify them, all devices must has their own and unique identifier assigned.

    • The authorization server must provide users with a way to review the authorization (consent) and accept or deny the device’s request for access.

      The users must be able to provide an informed decision whether they want to share their data or not. They need to know what requests access to their information and what data is requested.

  2. The end users must be able to authenticate with their identity source.

    Before the user grants their authorization, they need to authenticate to prove their identity (thus prevent unauthorized access to data).

Device Flow: Access Control with Cloudentity

To enable organizations to enforce both coarse-grained and fine-grained authorization for devices, the Cloudentity authorization server is capable of enforcing access control using the OAuth 2.0 Device Authorization Grant (Device Flow). With Cloudentity, an organization not only does not need to implement their own solution, but also receives a platform that is tailored for authorization and access control.

With Cloudentity, organizations can:

  1. Use Cloudentity built-in authorization server configured to enforce access control using OAuth 2.0 Device Authorization Grant (Device Flow).

    • The authorization server can generate and verify device and user codes.

    • Administrators are provided with flexible configuration on user code length and charactes sets via the administrative portal or Admin level APIs.

    • Dynamic or static client registration to utilize the Device Authorization.

    • Brandable consent page. If provided branding is not sufficient, you may create and integrate your own consent page using Cloudentity APIs.

    • Brandable device code displayed for the end users.

    • Access can be easily controlled at:

      • The service level

        Users based on their subscription level and pricing plan may have access to different services.

      • The resource (data) level

        Access to resources is determined on additional conditions like, for example, location, time range, and others.

      Best Practices

      It is considered a security best practice to limit access to services and data to the resources that are absolutely necessary at the given moment.

  2. Enable their customers to authenticate with their identity source.

    • It is recommended to use services that can also enforce mechanisms like two-factor authentication or multi-factor authentication.

    • Besides the customers, think of your employees too. They need to be provided with the same tools.

    • User authentication is done using identity provider services either available on the market or built in-house.

Authorization for Devices Summary

If an organization needs to enforce access control for input constrained devices, OAuth 2.0 Device Authorization Grant (Flow) is the OAuth authorization grant type that should be used to enable users to provide their authorization with optimal user experience. Cloudentity delivers Device Flow capabilites as part of its platform. Set up a free tenant and try it yourself!