# Consent and devices

> The consent screen an application's request can show, its loading and failure states, and connecting a device with a user code at /device.

## Consent

A request with `prompt=consent`, or one a client must ask for, shows `/consent` after the
user is signed in. Everything on it comes from the server's reading of the validated
request, never from the address bar: the application, the account, each permission, the
service the access is limited to, and a warning when the request carries structured details
the screen cannot show. See [Sessions, Consent & Logout](https://www.nauthera.io/docs/v1/sessions#consent).

```mermaid
flowchart LR
  S[Signed in] --> C["/consent"]
  C -->|Allow| CB([Back to the application with a code])
  C -->|Deny| E([Back with access_denied])
  C -->|Switch account| L["/login"]
```

<StoryScreenshot id="screens-consent--loading" alt="Loading the request…" />
<StoryScreenshot id="screens-consent--default" alt="Authorize the application: the account and each permission, with Allow and Deny" />
<StoryScreenshot id="screens-consent--restricted-to-resource" alt="Consent with the access limited to one service" />
<StoryScreenshot id="screens-consent--authorization-details" alt="Consent warning that the request asks for a specific action" />

**Allow** returns a code to the application; **Deny** returns `access_denied`. A grant is
remembered, so the same request is not asked again. A request the server can no longer
describe shows no permission list at all, with **Sign in** to start over:

<StoryScreenshot id="screens-consent--load-failed" alt="We could not load this request, with Sign in" />

## Connect a device

A device using the device flow (RFC 8628) shows a code and the address `/device`. The user
opens it, signs in if needed, enters the code, and approves.

```mermaid
flowchart LR
  D["/device"] -->|code| A[Connect the device?]
  A -->|Connect| OK[Device connected]
  A -->|Cancel| NO[Device not connected]
  D -->|too many wrong codes| B[Too many incorrect codes]
```

<StoryScreenshot id="screens-device-code--default" alt="Connect a device: enter the code shown on your device" />
<StoryScreenshot id="screens-device-code--invalid-code" alt="That code is not valid or has expired" />
<StoryScreenshot id="screens-device-approve--default" alt="Connect the device? The code to match, the account, the permissions and the expiry" />
<StoryScreenshot id="screens-device-result--approved" alt="Device connected: you can go back to the device" />
<StoryScreenshot id="screens-device-blocked--blocked" alt="Too many incorrect codes: start again on your device" />

A device's own address can fill the code in. The approval names the account, with
**Switch account**, and how long the request has left. Wrong codes are refused one at a
time; too many stop the request, and the device has to start again.