We have a new web project where we have decided to use identityserver as a centralised identity management service. The idea being long term we can migrate other projects to this and maintain users in one place.
The site itself consists of an angular SPA (client), a web api backend (api resource) and a separate aspnet core MVC site running identity server.
Users follow an openid connect flow, redirecting from the frontend to the identity server to login, then using the resulting access token to connect to the API.
All of this works fine, and we can consume basic user data in the API from the access token such as subject, email, name etc.
So far, fine.
The problem is that we have some additional profile data which is specific to the application - in the original design (without identity server) this was all contained in a single JWT so it was very easy to consume from the frontend, backend or via built in middleware like ASP.net identity.
Our workaround this is that the client has to make a call to the API after login to retrieve a separate token from the API containing profile data specific to this problem domain - for example permissions and roles that the user has in this system.
This last step feels somewhat clunky to me. For example, we cannot now use ASPNET identity in the API to get the roles because they are in the second token not the access token.
Is there any best practice or approach to to handle this scenario?
e.g. should we make identity server request the profile data from the API when at login time or is this bad because identity server shouldn't know about the mechanics of the client?
Interesting question. I believe in this scenario I would use the "single responsibility principal". I would question who has the ability "response-ability" to provide the profile data. If it is your application than yea u are heading in right direction in getting the profile info from the API itself. If it is in the ability of the identity provider than go ahead and implement it the identity provider. Architecture is about decisions and a good architecture would allow you to change those decisions with ease, hence if profile is just for that app then keep it in that app. Hope it makes sense.