I am wondering if it’s possible to use the OAuth2 device flow to authenticate devices (TV’s) that are input-constrained: I have a process in mind where on initial set up of the TV’s, installers have to use their secondary device (smartphone) to authenticate the TV’s by entering a device code that is shown on-screen.
But in the regular OAuth2 device flow, the access tokens the TV’s receive are then bound to that specific installer’s user_id. I’d like to have a system where the TV’s itself are the the “resource owner”. But is it somehow possible to bind access tokens to a device id instead of a user id?
Since the TV’s could be located in public areas, they cannot be considered safe to store a client_secret. So I guess that I’m not able to use the client_credentials flow in this case, where the tokens would not bound to a specific user.
Thanks in advance for any ideas or suggestions!
Stephen
Yes, I don’t think the scenario you described with the identity tied to the device and the not the user is not supported. Client Credentials is not a good match either, as the identity is tied to the Client ID, so a single client for all the devices . Resource Owner could be, but you need to assign a username/password to the device. Also, you are right about the TV being a public client, so you can not store secrets on it.
A solution I thought of was to build some kind of Device Flow ‘proxy’ server where the installer users sign in and can authorize new devices into the system. It would sit in between the TV’s and the OAuth2 server.
TV’s would be requesting access using device codes like the regular Device Flow, and these codes need to be scanned or entered by installers, but the proxy server would return device-bound tokens instead of installer-bound tokens. Since this proxy server can be considered a private client, I would be able to use the Resource Owner flow from there to the OAuth2 server, BUT then I need to have access to a database with usernames and passwords linked with the TV’s. The passwords also have to be stored in plaintext, which is something I really want to avoid…
Do you think that this is an acceptable approach, or am I thinking too much out of the box?
I don’t know exactly your business requirements, but yes, that’s an option. I can think in a few alternatives,
Just use one user for all your installers (so all the devices under a single account), and you pass the device identity information as payload to your backend APIs together with the token for the generic account. Cons: An unique generic user that needs to be reused and it can be compromised.
Register a new account in Auth0 for each device, so you actually authenticate with an username/password associated to the device. Cons: Too many accounts registered in Auth0. Username/Password must be kept for each device
Similar to your approach. Create a custom API key service that authenticates with the device token and returns a key as exchange… You keep that key in the device and use it for other API calls. Cons: You need to implement this yourself.
Just wanted to let the community know that I came across this thread trying to solve a similar problem.
It’d be great to have the capability to use the OAuth Device Flow for machine-to-machine accounts. I also have an input constrained device but need it associated to the tenant instead of a user account.