Device Authorization Grant in PingFederate

1) What is the Device Authorization Grant?

The device authorization grant (RFC 8628) lets you authenticate users on input‑constrained devices (TVs, CLI tools, IoT, printers) that cannot show a full login UI. The device shows a short user code and a verification URL; the user completes sign‑in on a second device (phone/laptop). Meanwhile, the device polls the token endpoint using a device code until the user finishes.

Key tokens & codes

device_code — long, secret; used by the device to poll the token endpoint
user_code — short, human‑readable; typed by the user at the verification URL
verification_uri (and sometimes verification_uri_complete) — where the user finishes login and approval
interval — recommended polling interval (seconds)
expires_in — lifetime for the codes

2) Flow

3)How it fits with other grants

Auth Code + PKCE: Best for apps with a browser or in‑app web view.
Client Credentials: Machine‑to‑machine; no user.
Device Authorization: Best when no browser is available on the requesting device or the input method is limited.

4) PingFederate endpoints used in this flow

Device Authorization Endpoint: /as/device_authz.oauth2
User Authorization (Verification) Endpoint: /as/user_authz.oauth2
Token Endpoint: /as/token.oauth2

These paths are relative to your PF base URL, e.g., https://pf.example.com:9031.

5) Create the OAuth client for Device Authorization

Create one client per device‑type app (or per product family) with least privilege.

New Client
Admin Console → Applications → OAuth Clients → Add Client
Core settings

Client ID: e.g., tv-app-01
Secret / Auth Method: Optional or choose per your security model (confidential clients normally use a client secret)
Redirect URIs: Not used by device flow (leave empty unless the client will also use browser flows)
Allowed Grant Types: Device Authorization (and others if needed, e.g., refresh_token for long‑lived access)
Allowed Scopes: select the scopes you created (e.g., api, openid, profile)

Persistent grants / refresh tokens (optional)
If you want devices to keep access without prompting the user every time, enable Refresh Tokens (scope: offline_access) and configure lifetimes appropriately.
Bypass approval (optional)
For trusted first‑party devices, you may choose Bypass Authorization Approval to skip consent prompts. Keep this off for third‑party devices.

Save the client.

6) Testing through Postman

Request Device & User Codes

Device Authorization Request (POST)

URL: {{PF_BASE}}/as/device_authz.oauth2
Auth: Basic Auth (CLIENT_ID/CLIENT_SECRET) or form fields
Body (x‑www‑form‑urlencoded): scope=api openid profile

User Verification

The user visits the verification URI on a separate device:

Open verification_uri_complete directly, OR
Visit verification_uri and type the user_code.

Then, the user logs in via PingFederate’s login page and approves scopes.

Token Poller (POST)

URL: {{PF_BASE}}/as/token.oauth2
Auth: Basic Auth (CLIENT_ID/CLIENT_SECRET)
Body (x‑www‑form‑urlencoded):
grant_type=urn:ietf:params:oauth:grant-type:device_code
device_code={{device_code}}
user_code={{user_code}}

Possible responses:

authorization_pending: keep polling.
slow_down: increase delay between polls.
expired_token: start over.
access_denied: user refused consent.

Success:
You’ll get an access_token, refresh_token (if enabled), and possibly an id_token.

The device authorization grant in PingFederate is the perfect choice when you need secure user login from devices without browsers. With the right configuration, you can enable TVs, IoT, and terminals to authenticate users easily, without compromising on security.

Also Read

The below rest of the articles give you the more information about the OAuth in PinFederate. You may love reading them.