CODEWITHSUNDEEP
keycloakreverse-proxyopenid-connect
Bragolgirith
Bragolgirith

Reputation: 2238

OpenID Connect: transparent authentication for legacy clients using Resource Owner Password Credentials

We're currently rewriting various services to use OpenID Connect (via Keycloak). This works great for any modern browser-based clients, but in our case we also need to support legacy IoT devices, which:

From the documentation we gathered that mapping each device to a Keycloak user and using the Resource Owner Password Credentials would be the way to go in such cases.

We were thinking that it'd be nice to add centralized support for such devices by exposing a reverse proxy that sits in front of all services and performs the following steps:

  1. Receive the IoT device requests (and optionally terminate SSL)
  2. Extract the credentials from the request (either basic auth / client certificate)
  3. Perform the Resource Owner Password Credentials Flow against Keycloak to exchange the credentials for an access token (where the IoT device acts as the OAuth Resource Owner and the reverse proxy acts as the OAuth Client
  4. If successful, enrich the original request with the retrieved access token and forward it to the proxied service

In that way the entire OpenID Connect authentication is transparent for any legacy devices.

This design could be further improved/optimized by caching the access tokens for the duration they are valid for (using the credentials as the cache key) and refreshing them when they expire.

Now, this idea seems like such a no-brainer, that we were surprised that we couldn't find any existing gateways, reverse proxies or plugins that do this. So I guess we're in need of a sanity check on:

UPDATE 1: (responding to question) The described legacy IoT devices are (physically) Arduino microcontrollers with baked-in unique credentials. In the context of Keycloak, each such Arduino microcontroller is mapped as a Keycloak user. We're open for suggestions if this is not the most adequate mapping for this use-case.

UPDATE 2: (responding to question) Agreed that the Client Credentials Flow would be semantically more correct for such a device-to-device authentication and any future devices we produce will use it. However we can't use it for the existing legacy devices for two reasons: 1) the devices only know the server's URL and can't authenticate directly against Keycloak and 2) we also want to support SSL Client Authentication using a X.509 certificate and from our understanding Keycloak only supports X.509 client certificate user authentication for users, and not for clients.

Upvotes: 1

Views: 829

Answers (1)

user229044
user229044

Reputation: 239312

Is this something that can work as described or are there any obvious flaws with the idea?

It works fine, so long as your OP supports the Resource Owner Password Credentials flow, which is deprecated and removed from modern OAuth2.

Why isn't anyone doing this already? (assuming that supporting legacy devices is a major pain point when switching to OpenID Connect)

Lots of reverse proxies do this, just not with resource owner credentials. The ROPC flow was never a good idea, exists for legacy reasons, and has been removed from OAuth 2.1.

I suspect that most people move away from storing and transmitting resource owner credentials as they modernize their architecture.

Upvotes: 1

Related Questions