In instances where you have multiple clients and a central IdentityServer 4 instance which handles user auth/n, how would you go about managing user profiles from individual clients?
Current scenario:
- user clicks on manage profile
- user is redirected to a custom manage claims page on IdentityServer which a) loads all claims in a form, b) allows user to mod such claims and c) updates them with new values
- user is redirected to the referrer URL (which then retrieves these fresh claims via a token refresh which includes the profile scope) - although a redirect is not always possible, or is frowned upon from a design perspective (users' experience is broken since they are taken to a different location with a different design).
Desired scenario:
- user clicks on manage profile
- user is redirected to a profile page on the client itself (e.g. SPA or desktop), populated with info from the profile scope
- user updates profile data, and client then makes an API call to IdentityServer to update the users' claims centrally
- local claims are refreshed to reflect claims sent to Identity Server
Main concern: is this a sound approach architecturally speaking? Should user profiles (e.g. first/last name, gender, DoB, etc...) be managed by IdentityServer (via an API or own pages) or should these be stored centrally and used/managed by both IdentityServer (loaded as claims) and individual client apps? How would you go about tackling the desired scenario?
The closest info I got was in method 3 discussed here.
... however it's a 3+ year old doc, and am not sure what is recommended by oidc-client/IdentityServer 4 devs today.
Any insights would be highly appreciated.
Chris