Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add device flow documentation #2026

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
132 changes: 132 additions & 0 deletions docs/oauth2-oidc/device-authorization.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,132 @@
---
id: device-authorization
title: Device Authorization
sidebar_label: Device authorization flow
---

The OAuth 2.0 Device Authorization Grant (also known as Device Flow) is OAuth 2.0 extension that enables devices with no browser
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The OAuth 2.0 Device Authorization Grant (also known as Device Flow) is OAuth 2.0 extension that enables devices with no browser
The OAuth 2.0 Device Authorization Grant -also known as Device Flow- is OAuth 2.0 extension that enables devices with no browser

generally try to avoid parentheses in text

or limited input capability to obtain an access token. It enables users to authenticate devices with limited input capabilities,
such as smart TVs, gaming consoles, or IoT devices, by delegating the authentication process to another device with a full browser
(e.g., a smartphone or computer).
Comment on lines +9 to +10
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
such as smart TVs, gaming consoles, or IoT devices, by delegating the authentication process to another device with a full browser
(e.g., a smartphone or computer).
such as smart TVs, gaming consoles, or IoT devices, by delegating the authentication process to another device with a full browser such as a smartphone or computer.

avoid abbreviations like e.g.


This document provides an overview of the Device Authorization Grant, a step-by-step example of its implementation, configuration
options, and guidance on creating custom user interfaces for the verification screen.

## Overview of the Flow
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Overview of the Flow
## Overview of the flow

sentence casing in headlines


Here is the high-level overview for the Device Authorization Flow:

1. The device requests to be authorized from the Authorization server.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is "Authorization server" a term that is specific to this flow here?

If yes I would say capitalize it as "Authorization Server"; pelase use "authorization server" throughout the document.

2. The user is instructed to visit a URL on a different device and is given a user code.
3. On a different device the user, visits the URL, provides the user code, logs in and grants access to the device.
4. The device polls the Authorization server. Once the user authenticates and grants access, an access token is returned that can
Comment on lines +20 to +22
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
2. The user is instructed to visit a URL on a different device and is given a user code.
3. On a different device the user, visits the URL, provides the user code, logs in and grants access to the device.
4. The device polls the Authorization server. Once the user authenticates and grants access, an access token is returned that can
1. The user is instructed to visit a URL on a different device and is given a user code.
1. On a different device the user, visits the URL, provides the user code, logs in and grants access to the device.
1. The device polls the Authorization server. Once the user authenticates and grants access, an access token is returned that can

markdown should number this automatically

be used to access the protected resource.

### Step 1: Device Requests Authorization
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally not a fan of "Step X:" in headlines.
However I can't think of a better way to express this here 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Step 1: Device Requests Authorization
### Step 1: Device requests authorization


The user tries to log in in the limited input device. The device sends a POST request to the Authorization server to initiate the
flow with the following parameters:

- `client_id`: The ID of the client that is making the request.
- `scope` (optional): The scope of the access request, which specifies what resources the requesting application can access.

The Authorization server responds with the following information:

- `device_code`: A unique code to identify the authorization request.
- `user_code`: A code the user will enter at the verification URL.
- `verification_uri`: The URL where the user can authorize the device.
- `verification_uri_complete`: The URL where the user can authorize the device, with the user_code already filled in.
- `expires_in`: The lifespan of the device code (in seconds).
- `interval`: The polling interval (in seconds) for the client to check if the user has authorized the device.

---
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
---

no <hr/> please


## Step 2: Display User Code and Verification URL
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Step 2: Display User Code and Verification URL
## Step 2: Display user code and verification URI

is it URL or URI?


The device shows the user the `user_code` and `verification_uri` it received from the OAuth server.

The user visits the provided URL on a separate device (e.g., a smartphone) and enters the code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The user visits the provided URL on a separate device (e.g., a smartphone) and enters the code.
The user visits the provided URL on a separate device such as a smartphone and enters the code.

same as above


## Step 3: User Grants Permission
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Step 3: User Grants Permission
## Step 3: User grants permission

see above


Once the user enters the code, they are prompted to log in (if not already authenticated) and grant or deny permission to the
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Once the user enters the code, they are prompted to log in (if not already authenticated) and grant or deny permission to the
Once the user enters the code, they are prompted to log in if not already authenticated and grant or deny permission to the

same as above

client. After granting permission, the user is redirected to a page confirming successful login.

## Step 4: Device Polls for the Access Token
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Step 4: Device Polls for the Access Token
## Step 4: Device polls for the access token

see above


While the user is authorizing the device, the device polls the `token` endpoint of the Authorization server to check whether the
user has completed the authorization process, by making a POST request with the following parameters:

- `client_id`: The ID of the client that is making the request.
- `device_code`: The device code received from the device authorization request.
- `grant_type`: This should always be `urn:ietf:params:oauth:grant-type:device_code`.

After the user grants permission, the Authorization server will respond with an access token.

## Configuration Options
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

best practice would be to have some text under each headline, not sure what you could write in this case 🤔

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Configuration Options
## Configuration options

see above


### Configuring the UI
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Configuring the UI
### Configuring the user interface

no abbreviations in headlines


To enable and configure the Device Authorization Grant in Hydra, adjust the following settings in your Hydra configuration file:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To enable and configure the Device Authorization Grant in Hydra, adjust the following settings in your Hydra configuration file:
To enable and configure the Device Authorization Grant in Ory Hydra, adjust the following settings in your configuration file:


```
urls:
device:
verification: http://path/to/device/verification/ui
success: http://path/to/device/success
```

### Configuring user_code entropy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Configuring user_code entropy
### Configuring user code entropy

avoid "code" syntac in headlines


Depending on your security needs and your traffic load, you may wish to enhance your user_code entropy. The hydra
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Depending on your security needs and your traffic load, you may wish to enhance your user_code entropy. The hydra
Depending on your security needs and your traffic load, you may wish to enhance your user_code entropy. The Ory Hydra

always use the correct service name

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Depending on your security needs and your traffic load, you may wish to enhance your user_code entropy. The hydra
Depending on your security needs and your traffic load, you may wish to enhance your `user_code` entropy. The hydra

`oauth2.device_authorization.user_code_entropy` configuration supports 3 values:

- `high`: user_code is 8 characters long and consists of alphanumeric characters, excluding some ambiguous symbols
- `medium`: user_code is 8 characters long and consists only of upper case letter
- `low`: user_code is 9 characters long and consists of numbers
Comment on lines +84 to +86
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- `high`: user_code is 8 characters long and consists of alphanumeric characters, excluding some ambiguous symbols
- `medium`: user_code is 8 characters long and consists only of upper case letter
- `low`: user_code is 9 characters long and consists of numbers
- `high`: `user_code` is 8 characters long and consists of alphanumeric characters, excluding some ambiguous symbols
- `medium`: `user_code` is 8 characters long and consists only of upper case letter
- `low`: `user_code` is 9 characters long and consists of numbers


Keep in mind that higher entropy may make it harder for the user to enter the user_code.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Keep in mind that higher entropy may make it harder for the user to enter the user_code.
Keep in mind that higher entropy may make it harder for the user to enter the code.


## Device Verification UI implementation
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Device Verification UI implementation
## Device verification user interface implementation


Here is a sample implementation for a device verification UI :

```js
import { Configuration, OAuth2Api } from "@ory/client"
import { Request, Response } from "express"

const ory = new OAuth2Api(
new Configuration({
basePath: `https://${process.env.ORY_PROJECT_SLUG}.projects.oryapis.com`,
accessToken: process.env.ORY_API_KEY,
}),
)

// Please note that this is an example implementation.
// In a production app, please add proper error handling.
export async function handleLogin(request: Request, response: Response) {
const challenge = request.query.device_challenge.toString()
const userCode = request.query.user_code.toString()

// Show the login form if the form was not submitted.
if (request.method === "GET") {
response.render("device", {
challenge,
userCode,
})
return
}

// User was authenticated successfully,
return await ory
.acceptUserCodeRequest({
deviceChallenge: challenge,
acceptDeviceUserCodeRequest: {
user_code: userCode,
},
})
.then(({ redirect_to }) => {
response.redirect(String(redirect_to))
})
}
```
Loading