Device Authorization Grant - how to represent multiple devices

Hi,
We are trying to integrate Device Authorization Grant.
We have successfully created a single client that represents all devices (e.g. client is something generic like “smart_tv” and there maybe multiple TV devices around). We have successfully managed to obtain tokens on our devices using Device Authorization Grant flow.

But the idea is that one user needs to grant access to multiple devices.

As far as we can see, as long as we are granting access (using verification_uri_complete) from a single browser session, they are represented as a single client entry in a single session. I.e. we can see that the user has a session associated with the client that represents device, but there is no way to find that acutally 5 different devices obtained their tokens.
This means, that we are not able to “log out” devices selectively - we can only terminate the session for all devices at once.

Is it intended behaviour?

Also, is it OK to model device type as a single client? Or maybe we should create a new client for each instance of a device? But this seems odd, because we might need to support thousands of such devices.

1 Like

I have a similar use case and I am wondering the same thing. Did you figure out a way?

I am guessing one way would be to use a client for each device. Give your user access to each client and you should be able to see all the clients the user gave its consent for in the user’s content tab. You can remove the consent for a particular client (i.e device) which should disallow any tokens generated for this client from working.

Sadly, the issue you now have is that on top of coordinating the device oauth2 flow on the device side of things, you now need to precede it by the coordination of the client creation…

Base on my understanding you have the following options for that:

  1. Create the client manually in the keycloak admin console.

  2. Kick off the registration logic from another app that is allowed to talk to keycloak via it’s admin api.

For either #1 or #2, by creating an oauth2 device flow client with pkce manually or programmatically should only impose on the device to deal with a client Id. You could make it so that the client id is the device id (whatever you find judicious to use).

  1. You could use the oauth2 dynamic client registration workflow. Problem is that the device needs to authenticate - and, as far as I understand, if you want to keep things safe, you will need to hand it an initial token to even allow that device from issuing a request for client creation. That handoff opens the door for yet more pain.

Any other options, you can think of? What did you end up doing?

Thx