Where to implement the user profile page using IdentityServer4?

1
votes

I have a solution with 3 projects in ASP.NET Core:

  1. MVC --- no DB (calls the API)
  2. Web API --- MySQL 5.7 own DB
  3. IdentityServer4 + ASP.NET Identity --- MySQL 5.7 own DB

I've managed to get authorization and authentication working between all three apps using in memory clients, users, resources following the great documentation found on https://identityserver4.readthedocs.io/.

Currently I'm using the HybridAndClientCredentials flow which works well with existing users as well as registered users. Newly registered users are saved in IdentityServer DB, using ASP.NET Identity tables.

The problems:

  1. One of my client requirements states that the user should have a profile page inside the MVC app to which the user should be redirected after he is authorized & authenticated successfully.

    What I'm doing right now is calling the API in the MVC app, OnTickedReceived event, with the initial claims to create the user in the API DB, but I have doubts that this is the correct implementation.

    Since the registration is done and persisted at IdentityServer level and some data about the user is stored there, should I make the profile page there too or should I make a call to the API somewhere in the registration flow to create the user in the API DB too, then redirect the user to the MVC app to input the rest of the details required for a complete profile?

  2. Another requirement states that a user should be able to grant read/write access to another user's details (as in linked accounts or something).

1
asp.net-coreoauth-2.0openid-connectidentityserver4

1 Answers

2
votes

Unfortunately, "it depends".

Let's start by asking "what is the profile page?". What information is on the profile page and is that information specific to your application (MVC/WebApi) or the identity management system.

IdentityServer supports the OIDC UserInfo Endpoint and Profile scope with ASP.NET Identity so that could work well. (http://openid.net/specs/openid-connect-core-1_0.html#UserInfo). You can insert IdentityClaims into the AspNetUserClaims table and get those back when you call the UserInfo endpoint.

But maybe this profile page mentioned in the requirements is information belonging to just the application's domain and therefore has no business being in the identity management system. Then, your current approach is ok- though maybe you could use a Filter Attribute instead of an authentication event (that's just a thought, might not be better).

To me, the decision is about who owns this so-called "profile" information. Is it the identity management system or your business application.

If the profile information can be shared across any client of the identity management system, then put it in the identity management system.