2

I have this project where I am using Identity Server 4 and Web API. The Web API is protected by the ID server project. As I understood, it is a better practice to have the ID server sit in its own project and have its own database. However, I am not sure how user registration should happen.I have my username and password sitting in the ID Server and the rest of the user details (fname, lname, dob, etc...) sittin in my main database. So how should the registration take place?

I thought maybe to create an api in the ID server to manage the user (create) and I call this API from the web api project. But how can I protect this signup service? Only the web api project should call it?

Not sure if I am going the right way with the registration so any suggestions are welcomed.

1 Answers1

2

You are going the right way - you should write something custom. Identity Server doesn't provide user registration OOTB, it just uses a database that is provided (or whatever other store).

Good thing here is that you have a complete freedom. You can create a completely separate (let's call it) "Admin" solution, that can do this job for you.

You can also (as you said) use the Identity Server solution, create the API there, protect it with IDS, and couple it with the services, that you use to communicate with your database.

m3n7alsnak3
  • 3,026
  • 1
  • 15
  • 24
  • ok so as a recap, I create apis in my IDS (signup as a start). I call this service from my Web API project. When the sign up service returns the User Id, i continue and save my business user entity in my main database with a foreign key if u want: the User Id from the IDS. correct? –  Feb 07 '18 at 08:50
  • Yes, but I would still suggest, to create this service(s) as a separate API. Lets not pollute the IDS. This API can (understand `should`) be protected by your IDS (except the anonymous methods that you need for initial registration). Then both the API and ids are using the same user database - the API for user management and the IDS for user authentication. Its cleaner and you have better single responsibility approach. – m3n7alsnak3 Feb 07 '18 at 16:53
  • I'm currently sitting close to where you are in this situation. I noticed that quickstart 6 uses ASP.NET identity and has registration controllers, but moving on to quickstart 7 where they have you make a Javascript client, all of that functionality gets left behind. I think that one way would be integrating it so that we keep the models/views created in quickstart 6. – JakeJ Feb 07 '18 at 18:16
  • Edit: Looks like it gets moved to a service, still trying to understand all the changes between 6 and 7. – JakeJ Feb 07 '18 at 18:27
  • QS 7 is not a successor of QS 6. It is a bit confusing, yes. But treat QS 7 as a sample for a JavaScript client. – m3n7alsnak3 Feb 07 '18 at 18:30