3

I am trying to figure out the correct authentication strategy and concepts for a single page web application (SPA) featuring local login as well as 3rd party login (e.g. Google, Auth0). Unfortunately, quite a number of articles on the matter seem get the concepts plain wrong.

The basic idea is that the browser and server would use an authentication token (e.g. JWT), so the server can check if the user is logged in/authenticated.

Questions and different opinions start where this token should be stored in the browser and how it gets to the server:

  1. In a cookie using HttpOnly (and preferrably secure, i.e. SSL only): some articles claim that cookies require server state and are old style - but I think they are wrong here. If the cookie was just a session ID, that the server would need to know, then this might be true, but in modern days, the cookie is the authentication token, that the server can just check.
    • PRO: gets to the server with no additional client-side JavaScript. This may be important if we used server-side rendering (SSR) to speed up SPA performance (e.g. via Angular Universal)
    • CON: vulnerable to XSRF/CSRF, but there are fixes for that
  2. In LocalStorage/SessionStorage
    • PRO: XSRF/CSRF not an issue
    • CON: vulnerable to XSS, but there are fixes for that. Biggest issue may be that it breaks SSR, as for the initial request, there is no client-side JavaScript that would send the token

My preference is slightly towards a JWT token stored as a cookie with some XSRF/CSRF protection added. This would look something like (XSRF omitted here): authentication 1

Am I missing something here?

How would an external authentication work with this? This would basically require JavaScript to run on the client, redirect to a form provided by the rd party server and after the user has entered user name and password on the external site, the auth server returns a token via JavaScript (basically a callback). Now what?

(Note that it do not think it is an option to enter user-name and password, send it to my web-server and the web-server talks to Google/Auth0. This is a no-go, as users should not be entering their password for a 3rd party site on my web-site).

The token I get from the external site can be validated, yes, but what purpose does it serve:

  1. it is used to directly send requests to my server (replacing the token/cookie) from my server? That would break the cookie-strategy, as I cannot save the token in the browser.
  2. it is sent to my server (replacing username/password) and the server - after checking - returns its JWT as a token.

Again, my preference is more towards 2, but I may be wrong here - or it might just the uncommon (which is a downside in security matters). This is what it would look like (again, XSRF omitted): authentication 2

(Not sure if I need to store the external token at all.)

Any thoughts or guidance?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.