Device Authorization

Good Evening All,

I am looking to make a non-interactive user that I want to give access to an account with an authorization code as the account is going to be accessed by an IoT device and only used as a display device for that account. I have tried using auth tokens but those seem to be api only, i am wanting to be able to access something behind Oauth possible accessing using a secret key

Hi @dan7,

Welcome to the Community!

To clarify, will an end-user need to log in to authorize the device, or is it two non-interactive clients that need to authenticate (for example a device needs to access a protected resource from an API)?

If an end-user needs to log in and authorize the device to access data on their behalf, then you can use the Device Authorization Flow.

If an end user is not involved in the authentication, but instead it is a non-interactive client that needs to access protected data, then you can use the Client Credentials Flow.

Thank you for getting back to me,

The process i was thinking of was as follows.

Device Boots up - > Device cURLs to auth0 to get a unique login link → device launches a chromium instance with said link → Chrome instance shows user as logged in

Hi @dan7,

Since it sounds like a user will log in to the browser, you can use Device Authorization Flow.

Here is a guide to implement this flow:

https://auth0.com/docs/flows/call-your-api-using-the-device-authorization-flow

Good Evening this is the flow that I have been trying, howerever it is a UI i am trying to access not an API, I am attempting to log the IoT device into a user account with no user interaction to be able to display a dashboard

Hi @dan7,

Is the UI protected? If so, you can still use device authorization flow to authenticate the user.

To clarify this, would you mind walking through what the flow would look like? If there is no user interaction at all, I’m not sure how the device will know whose account to display.

Thanks!

Hi @stephanie.chamblee,

Essentially, for the account authorization - we was hoping to give some sort of API key

The way I was thing is sort of like device authorization.

  1. Device Requests Access
  2. Auth server check credentials sent with request
  3. Auth server sends back a unique login link
  4. Device uses unique login link and opens up browser with given link - which when logged in will redirect to the clients dashboard. So i guess its sort of a magic link but without the email.

@stephanie.chamblee Any access to the system requires a login, I am simply trying to make that login headless

Hi @dan7,

The closest flow is still device flow. We don’t currently have a way to issue API keys in a flow exactly how you have described.

In device flow:

  • The device makes a device code request to Auth0 and Auth0 returns a device code and user verification link
  • The device shows the user the user verfication link to login. It polls Auth0 for a token until the user has logged in successfully (this can be through any type of connection such as log in with Google or the new passwordless with biometrics feature, etc.)
  • Auth0 returns an Access Token and ID Token that the device can use to get user profile info and make secure API requests

Alternatively, you can use client credentials flow, but there would not be good way to protect user accounts because the authentication would be scoped for the device instead of the user. The end user would be able to access any account that the device could access instead of the individual user.

@stephanie.chamblee

With the Client Credential flow, if we created a seperate Database just for devices - would they be able to login on the frontend or is this still only API?

When using Client Credentials, users would not be able to log in. This flow is used for two backend servers, and so the client (the device) would be authenticated instead of a particular user. Device flow is likely the best fit when you need to authenticate a user to a device.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.