Best practice: getting user data from keycloak

I need user data like e-mail etc. from keycloak in my spring boot application.

My solution would be: using the openid informations from the token, if available. If the token is not available or the application or users need access to some token informations from other users I would use the Keycloak Admin REST API. I am wondering why there is not more information about the best practice, does not nearly every application need user data?

Is this a good practice, i read a lot of saving the informations redundant in the app db but this seems to me like an anti pattern.

1 Like

Did you try userinfo_endpoint. It would be available /auth/realms/your relam/.well-known/openid-configuration

But where is the benefit compaired to the Keycloak Admin REST API?

Hey Jacob,
Let´s step a bit back and define your scenario. I try here as follows:
If you own both an app and the IDP you have several options. But be aware that that‘s usually not the case, and Keycloak is designed (based on OpenID-Connect for instance) to allow different scenarios.

Let’s start: The Admin API is what it is called - an admin API. So its great to push data into Keycloak, update data or remove data. The „data“ can be anything - users, groups (what you think about already) but basically also any data you create and maintain in the admin UI. The „drawback“ of the admin rest API is - it’s Keycloak specific. If your project /app needs to use a different IDP for some reason, you need to touch it.
Also, you „just“ want to read some user info, so you need only a small part of the power.

Another option you have in Keycloak as well as in mostly any IDP is to add data your app may need to the token on user login. This allows a specific app (your app) to gain specific information about the user (the IDP should have that data) in a „standard“ way. Still, the owner/manager of the IDP has to agree to that. If its you, its easy. If not, its a request to the relevant owner and it may be happening (or not).
I believe you see here the difference in flexibility.

Finally, the „userinfo“ endpoint. That’s even more powerful. It‘s standard, so it works cross-IDP (to my level of knowledge, and i talk about the behavior, not the formal url), but it adds the option of user consent. So let‘s say the owner of the IDP feels responsible about the data stored in it (he should anyway!), he may define that accessing some data in the user object (userinfo endpoint) requires the users consent before making it available to the app. Yes, there is the difference: the app wants (needs) the data, while the IDP cannot make the decision to share. Imagine an email address or even more sensitive a profile picture (or whatever data is there and is sensitive). So when your app requests the data the user would need to proof his „acceptance“ and be available and may have to log in.
The default config of Keycloak is that every client (app) can read all userinfo, but you can change that.
I hope this helps.

1 Like