Device authentication based on hardware specs

Dear readers,

Within my project, we currently don’t have the most secure solution for an identity server, which is why we want to implement Keycloak. So far we have concluded that it is a perfect fit for user-management and we would love to further explore the possibilities.

One feature we have in our current system is that devices follow a set of rules to determine whether they are granted access to our systems. Think about IP-validation, app-validation against computer serial number, the device making itself known and being whitelisted in our systems, etc.

These rules are part of our current “device multi factor” authentication. The issue we have is, we cannot find functionality within keycloak that covers this specific need. We have found the device code flow, and are planning on using this, but this does not solve our previous issue.

This device code flow requires a user to authenticate a device through inputting a code of some sorts. The issue compared to our current situation is that, as of now, users are only required to log in once through scanning a code. Don’t get me wrong, we are aware this is not the best solution and we are looking at 2fa devices to replace these codes, but this together with a strict device-management is sufficient for our situation, for now.

We don’t want to make it harder for our users, since they vary quite a lot in nationality and smarts. Some people simply cannot remember a password, and some cannot read english or any other languages that we translated our apps in.

The question that I am asking here is as follows:
- How can we ensure our devices are ‘safe’ without hindering the users whom use these devices, compared to our current situation?

Is there any option within keycloak for this?

We have thought about creating an application that authenticates devices, from where the users can be authenticated within keycloak, if these devices are authenticated.
We have also thought about removing these multi-factors from the device-authentication, but we simply cannot take this risk.

We are looking forward to the responses!