0

I have 2 ASP .Net projects each with its own database:

  • Identity App: acts as an authorization server with its own database that contains user info. Uses identity 4: Oauth 2.0 and OpenId (code flow)
  • Resource App: Api that returns access to multiple resources. (database doesn't include anything about users)

Our front end communicates with the resource app mainly and uses the identity app for authorization. Now we are developing the functionality to add a user from the front end and to get all the users.

My questions:

  • Should the frontend communicate directly with the Identity App to get the users?
  • If not, how can I get the user info through the resource app?

I tried the following flow for adding a user but it didn't work:

  1. Frontend posts user to resource API (Note: the user is already authenticated using the authorization server)
  2. I use the authorization header in that request to build a rest sharp request to the authorization server
  3. The authorization server isn't recognizing the bearer token
Nick
  • 165
  • 2
  • 18
  • Please note that these are seperate contexts and within each context the user / person has a different purpose. Please read my answer [here](https://stackoverflow.com/questions/52079466/#52100609) for a more detailed explanation. –  Nov 29 '19 at 16:52

1 Answers1

0

I'd recommend storing the majority of user data in the resource app's database.

Over time this will contain lots of fields that are nothing to do with OAuth, such as app specific preferences.

Meanwhile you also need to store a few fields related to login in the identity app: name, password etc.

My write up may help you to understand the separation and achieve your goals: https://authguidance.com/2017/10/02/user-data/

Gary Archer
  • 22,534
  • 2
  • 12
  • 24
  • thank you for your answer. How can the resource API communicate with the Identity API to create a User for example? I tried using the authenticated user's bearer token in the header using Restsharp but it didn't work. – Nick Nov 30 '19 at 12:06
  • The authorization / identity server needs to expose user management APIs - systems such as Okta / Cognito / Azure Access Control all do this - usually in vendor specific ways. If you are using Identity Server you'll need to work out which operations you need and then implement them yourself. There are online examples: https://www.google.com/amp/s/damienbod.com/2016/11/18/extending-identity-in-identityserver4-to-manage-users-in-asp-net-core/amp/ – Gary Archer Dec 01 '19 at 08:59
  • This can quickly turn into a lot of work though - especially when you consider stuff like auditing and reporting. If you can use a cloud provider as above you'll get a lot of this for free. However, you'll also have to accept the vendor login user experience. This is the big trade off in moving to OAuth really. – Gary Archer Dec 01 '19 at 09:05