Authentication for SPA hosted on same domain as API leveraging SameSite cookies

user_2495297 0
Viewed 353

I am thinking about how I will implement authentication in my react application and even after hours of reading I still have few questions. Please provide any information you think could benefit me I would like to really understand the problem it could be that my line of reasoning somewhere implies I don't fully understand something I would appreciate if you could point out where I am wrong.

Infrastructure:

  • SSR React app served behind reverse proxy on <domain_name>
  • .NET 5.0 api server using asp.net identity served behind reverse proxy on api.<domain_name>
  • Reverse proxy provides SSL so https:// on both

General information:

  • I need to support external logins (Google, Facebook etc)
  • Paying for Auth0, Okta etc is not an option
  • No 3rd party apps are going to authenticate against me
  • Client is web browser
  • I don't need to support outdated browsers

Questions:

  • Do I need IdentityServer4 at all? I am never going to act as an authentication authority for 3rd party apps.
  • I can still support external logins without using IS4 right? I just need to handle redirect callback I can see there are methods such as GetExternalLoginInfoAsync, ExternalLoginSignInAsync which should make the job easier.
  • The reason why every SPA authentication tutorial recommends Auth Code + PKCE is because they assume you want to be authentication authority, don't have API on the same domain, or were written before SameSite cookies existed?

My plan is to write a custom login route assigning SameSite cookie and that's it. This makes client-side code super simple no shenanigans with adding access tokens to headers before making calls.

Is it possible? I found few articles describing something very similar but I am not sure.

With a setup like that is there something that is just not going to be possible? Like remote logout, banning users, or whatever you can think of.

identityserver4 asp.net-identity reactjs authentication asp.net
1 Answers

You don't have to implement IS4 if you don't want to (especially since IS4 will have its support shut down in November 2022). You can just read the OAUTH2 documentation and implement the routes you need and still be OAUTH2 compliant.

You will have only one client (your react app) so no dynamic client registration, just the 2 following routes:

  • the authorization endpoint to get an authorization code when the user successfully authenticated himself using an external provider. This authorization code has to be used ONLY ONCE in the next route.

  • the token endpoint to get an access token and a refresh token using the authorization code given above or a refresh token given before. If the same authorization code or refresh token is used twice, you have to revoke the tokens given in the first call because this should not happen.

With a setup like that is there something that is just not going to be possible? Like remote logout, banning users, or whatever you can think of.

Besides these 2 routes you are free to implement whatever you want. Like a route to allow user to revoke all of his sessions.

To answer more precisely to your questions:

Do I need IdentityServer4 at all? I am never going to act as an authentication authority for 3rd party apps.

No you don't need it if you don't know exactly why you need it. It does not have anything to do with the fact that you are not going to act as an authentication authority for others clients.

I can still support external logins without using IS4 right? I just need to handle redirect callback I can see there are methods such as GetExternalLoginInfoAsync, ExternalLoginSignInAsync which should make the job easier.

Yes you can, as long as you store the authorization code and the refresh token when the user successfully signed in using the external provider.

The reason why every SPA authentication tutorial recommends Auth Code + PKCE is because they assume you want to be authentication authority, don't have API on the same domain, or were written before SameSite cookies existed?

I would assume that they are oriented Oauth2 compliance. But if you don't need nor want to implement OAuth2 framework, then don't. But in my opinion you should, it is really easy to implement.

user_78218570
Related