0
votes

Im searching solution about authentication. I found IdentityServer and Im trying understand how it works. In my case I need to check user exist in another app. I have old project created in asp.net web froms and this project have a users collection stored in db. Now I must create client who will be call to WebApi and in this WebApi I need to authenticate user. I want to do this using IdentityServer4. Can I in IdentityServer call to my old application or db this application and check user by custom method?

In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways. When request will be form new app IdentityServer should check user in his db and if request is from client who will be call to old app should check this user in external app(db).

Example call: enter image description here

I dont know I good understand idea of IdentityServer, but generaly I think this is not good solution for my case...For now I understand I can store users in database but only with Asp.Identity in IdentityServer.

What do you think about this case ?

In future I want connect another application to IdentityServer and this new application should have users in IdentityServer, so I will be have two places where I will have users for two application. I need to be sure I can check user exist in this two ways. When request will be from new app, IdentityServer should check user in his db and if request is from client who will be call to old app, should check this user in external app(db).

1

1 Answers

1
votes

The short answer is that IdentityServer4 is just an implementation of the OpenID Connect protocol and the persistence and authentication of users is entirely customisable so you're free to implement that any way you like.

As for where to keep your users - that will depend on your problem domain and business rules but I'd probably try and avoid using multiple DBs if possible and instead migrate existing users from legacy applications to your identity service's own store and take care to only bring over identity and authentication information and not access control/authorization information. i.e. keep the authorization logic in your client applications and APIs.