Should each device get a user in Keycloak authenticated through Resource Owner Password Credentials

user_15268208 0
Viewed 1115

I am implementing an authentication system in Keycloak with human users and iot devices.

Human Users: Access the system through a spa and use the Standard Redirection Based Authentication Flow.

IOT Devices: The use case involves a number of high value devices which not interactive and need to transmit telemetry to the backend and access their own data as well data from associated users. My current plan is to use the Resource Owner Password Credentials Grant since the embedded system can be setup with credentials during provisioning.

My thinking is that this would enable me to use Keycloak Groups and Roles for permission management and User <-> Device Association.

Is there anything inherently wrong with this approach?

keycloak openid-connect oauth
1 Answers

My current plan is to use the Resource Owner Password Credentials Grant since the embedded system can be setup with credentials during provisioning.

From source one can read:

The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application. The authorization server should take special care when enabling this grant type and only allow it when other flows are not viable.

This grant type is suitable for clients capable of obtaining the resource owner’s credentials (username and password, typically using an interactive form). It is also used to migrate existing clients using direct authentication schemes such as HTTP Basic or Digest authentication to OAuth by converting the stored credentials to an access token:

Does your use-case meets those constrains?

If no, consider using The Client Credentials Grant instead:

With machine-to-machine (M2M) applications, such as CLIs, daemons, or services running on your back-end, the system authenticates and authorizes the app rather than a user. For this scenario, typical authentication schemes like username + password or social logins don't make sense. Instead, M2M apps use the Client Credentials Flow (defined in OAuth 2.0 RFC 6749, section 4.4), in which they pass along their Client ID and Client Secret to authenticate themselves and get a token.

So in the latter instead of using the username and password for authentication you would be using a client secret instead.

My thinking is that this would enable me to use Keycloak Groups and Roles for permission management and User <-> Device Association.

You can still add claims to the confidential client as well and use them for permission management.

user_13668710
Related