CODEWITHSUNDEEP
asp.netoauth-2.0single-page-applicationidentityserver4openid-connect
Chris Porter
Chris Porter

Reputation: 43

IdentityServer, clients and user profile management

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:

  1. user clicks on manage profile
  2. 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
  3. 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:

  1. user clicks on manage profile
  2. user is redirected to a profile page on the client itself (e.g. SPA or desktop), populated with info from the profile scope
  3. user updates profile data, and client then makes an API call to IdentityServer to update the users' claims centrally
  4. 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

Upvotes: 4

Views: 2005

Answers (1)

Wiktor Zychla
Wiktor Zychla

Reputation: 48250

I believe the main reason for the need of the second scenario could possibly be

taken to a different location with different design

Is it?

If it's not, I don't see any benefit from repeating the same or similar claim update page on multiple client apps, if there are more than one.

If it is and you can't customize the page on your identity provider (the Identity Server), you can still have a single claim update page but just hosted outside of the Identity Server. This page (formally: the app that hosts it) would be the client of the identity provider as well as the client app that redirects here.

A benefit of this approach is that you could have a total control of how this page looks like, event make it conditional depending on the client.

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 IdentityServe

There is no single answer to this as it totally depends on you actual business background.

It's even worse than you describe, you can have a hybrid system where some claims are shared by multiple subsystems but other subsystems have their own profiles not shared with any other subsystems and all these are integrated around one identity provider.

Upvotes: 2

Related Questions