2

So from what I have read on IdentityServer I should be storing details about the user such as first name and last name inside claims. How would a web application then be able to access the claim information? Since the User Info endpoint requires a valid access token representing the user, I suppose I would need to make an API that could access that returned the profile information of other users? Is this the right way to do it? (use case, web page needs to display contact details that are stored in claims of another user)

Also what would be the way for multiple language profile information be stored and retrieved in the claims? For example a user can have a name/title in multiple languages. I'm thinking of making [LanguageCode]_[ClaimType] (fr_first_name) naming convention and either adding all languages to just the profile IdentityResource or creating separate resources per language.

jonmeyer
  • 748
  • 8
  • 22
  • have you tried looking at the token? web apps can just read the claims directly from the token userinfo end point is really only needed if you want refreshed data. https://jwt.io/ – Linda Lawton - DaImTo Mar 16 '18 at 12:28
  • @DaImTo What do you mean "token userinfo end point", those are two separate end points as far as I know. Per the documentation the userinfo end point requires the access token from the logged in user, I could try it with with an access token generated by the token endpoint with client credentials, but i thought the documentation said otherwise. – jonmeyer Mar 16 '18 at 13:55

1 Answers1

3

Your best bet is to set up a project using the IdentityServer4 QuickstartUI example and review that code to better understand how it all works. As of version 4, Identity Server is only focused on the sign-in / sign-out process and the various flows around authentication. They also provide a basic EF-driven persistence model, and they also support the ASP.NET Core Identity persistence model (also EF-driven), but both of those are not meant to be production-ready code.

Basically, persistence of user details is considered your responsibility. That being said, the cookies used for ASP.NET Core authentication greatly restricts how much data you can/should store as claims. The best model is to keep "real" identity provider (IDP) claims as claims, don't add new claims to that list, copy what you need into some other separate user-data table you manage completely, and use the unique claims identifier (almost always "subject id") as the key to your user data. This also makes it easier to migrate a user to another IDP (for example, you'll know user details for "Bob" but he can re-associate his user data away from his Facebook OIDC auth to his Google auth).

Basic persistence isn't too difficult (it's only 12 or 13 SQL statements) but it's a lot more than will fit in a Stackoverflow answer. I blogged about a non-EF approach here -- also not production-ready code (for example, it has ad-hoc SQL to keep things simple), but it should get you started.

McGuireV10
  • 9,572
  • 5
  • 48
  • 64
  • I aggree with McGuireV10, just create a database for the user info and keep it separated from identity server. If you have a service oriented system just create an Account service to manage user information. You want to minimize the size of the tokens and the attack surface (security wise) on identity service. – Andre Dec 13 '18 at 00:56