Search code examples
securityauthenticationsingle-sign-ontoken

which authentiation to use


Our application is currently written in .NET Framework + Razor, and traditional Membership authentication.

I am trying to modernize it, so I stawted to work on a .net core + react solution, but it has to cooperate with the existing application.

So currently, we have the old monolit, and an other .net core apis, called by react. The react is embedded inside the Razor.

Now I need to choose what authentication to use. I guess membership and other session based authentications can't be used, because there are multiple apps in multiple domains. So I need tokens.

I am not really sure about which solution can or should I use. I know buzzwords like bearer token, .NET Identity, OAuth + OpenId, but can I use any of them in this situation, to use it to protect the API and as well for the "traditional" razor app? And where should I store the token? Should I store it in a session of the razor app, and pass it to the React too?

I need a solution where user credentials are stored in our own database, not something list Google's or Facebook's single sign on.

Is there a good tutorial for this?


Solution

  • You're asking for a lot here. I would suggest brushing up on this topic from the beginning. If you only know the buzz words you won't get anywhere quick. I can give some quick advice but if you aren't familiar with the basics this won't really help. There is no quick solution for your answer.

    I would suggest authentication on the edge of the application to achieve a nice separation to work with the existing app. I would create a light weight method that receives the request from the client and gives the api gateway proof of the user identity in a way the API can verify. I would go with OAuth and OpenId Connect protocol to achieve this separation. Also, take a look at IdentityServer, it is an open source product that makes it easy to implement single sign-on and access control(Authentication) in web applications and HTTP APIs.

    • OpenId Connect to authenticate users
    • OAuth to limit collaboration for these light weight method calls
    • JSON Web Tokens (JWTs) for user identities

    Now the problem with this solution is that there is a high level of trust between this light weight method call and the rest of the system. The principle of defense in depth would suggest to implement a layering strategy, so that if this layer is compromised another layer is there as the next line of defense. I'll leave the rest up to you.