We use this at my company (Amplify) as a single "realm" configuration with Google and and a few other identity providers for "login with X". There's also some fun token exchange possible for any openid connect provider.
This means that I can swap Google access tokens for other access tokens and vice versa.
I'm also a contributor to the "frontend" piece of keycloak that's a JavaScript library called keycloak-connect (these are known as adapters).
Also also, I'm a maintainer of https://github.com/cdbattags/lua-resty-jwt that I'm using in tandem with the Keycloak RSA public keys for auth at API gateway/network level.
The best part is when you start chaining Keycloak instances together. We've had a couple cases where customers have wanted their own identity management, so we use an instance of Keycloak to connect to our central keycloak instances and to their solution of choice (Google, AzureAD, etc), and allows everyone to use their preferred identity platform.
I’m a bit confused...are you federating user management of those customers to their IDP? Or running separate keycloack instances for each of them? Or something else?
they could also just let them run their own keycloak instance and use that as the provider for the realm so customers can more easily debug it themselves.
it doesnt need much maintenance, so it doesnt really get easier than that.
Think it would be using brokering, the instance of Keycloak would be an external identity provider. Each customer would have their own instance of Keycloak that could then be configured to broker their choice of identity provider. I think this might be achievable at the realm level in a smaller scale deployment, i.e., using a separate realm for each customer but still chaining them back to the central realm through brokering, rather than spawning off new instances of Keycloak. Just a thought..
Keycloak links federated identities to its own user accounts, users can do this manually from the account management UI or it can automatically link them by email when a user signs in with a new IdP.
No configuration beyond setting up the federated provider required.
This means that I can swap Google access tokens for other access tokens and vice versa.
I'm also a contributor to the "frontend" piece of keycloak that's a JavaScript library called keycloak-connect (these are known as adapters).
Also also, I'm a maintainer of https://github.com/cdbattags/lua-resty-jwt that I'm using in tandem with the Keycloak RSA public keys for auth at API gateway/network level.
Ask me anything!