Using Azure AD as an identity provider in Keycloak-based applications: how can I add missing user data to my client applications?

Question

I'm currently using Azure AD as my identity provider and Keycloak as my intermediary/broker for my client applications. However, I need some user attributes (such as phone, email, picture, and officeLocation) that aren't provisioned from Azure to Keycloak by default.

I'm considering two options: fetching the additional data directly from the Graph API (which would require adding another system component and losing Keycloak autonomy), or adding the required claims to the access token and mapping them into the Keycloak database.

My question is, what's the best approach for accomplishing this? Is it possible to add custom claims to the access token and map them into the Keycloak database? Or is there a better way to get the additional user attributes from Azure AD?

Any advice or suggestions would be greatly appreciated. Thank you!

Answer 1

There is unfortunately no best answer here, Linus. Whether you add the data you mention to the claim or not entirely depends on the frequency of usage of the data.

If you are guaranteed to require the data for pretty much every single request, it may be beneficial to embed the data directly into the token as claims, like you said. On the other hand, if there are only a handful of situation where the data proves to be useful, having it always present in the token is a drawback because in most cases it would just introduce unnecessary data for transfer.

If I considered a complete generalization, I would generally try to keep the claims as small as possible and build some identity service, which is able to fetch additional user-profile information based on the provided token. This way the token remains relatively small and at the same time you have a local service where you can locally cache data so they are served very quickly.

• Laiv: And not coupled to either Azure nor Keycloak
• linus: I may not fully understand your comment, it seems to make some assumptions. Do you mean by using an external service you get some de-coupling?
• Andy: @linus, what Laiv meant by introducing your own identity service (acting as a proxy to AzureAD in your case), you abstract the Azure dependency behind your own proxy over which you have full control, pretty much introducing an anti-corruption layer. This is usually to your benefit, as potential change impacts due to changes in AzureAD are isolated to a single place in your ecosystem - the identity service.