I am trying to figure out a strategy for secure authentication - without re-inventing the wheel, but also considering the specific constraints of my situation. The strategy should not be tied to a particular framework - although I am looking at a node.js server with a REST API, serving an Angular web-app and also supporting server side rendering / Angular Universal - if that matters.

What may be specific about my situation is that I would like to support users allowing all features on their end, as well as users with a very restricted browser - potentially JavaScript and Cookies disabled. I have very little control over that. (I know, we could start to argue about this; it is 2018 and JavaScript is not that evil, but I have no control over the users, or they do not even control that themselves, but it is their IT department, ...). This seems to make things pretty complicated. Imagine the following scenarios: A user accesses the website, and first gets a server-side rendered HTML. Then either

  1. in a second step, the full web-app (e.g. Angular) is downloaded and replaces the pre-rendered page with the app. From now on, we are running a web-app
  2. user has disabled JavaScript or browser is too old, etc. so the HTML remains. User would use the web-site using server-rendered HTML

We can also assume the server to use https/ssl. At least here, I have full control. I do not currently need support for external / 3rd party authentication or a separate auth-server.

In general, I ran into the following strategies:

  • Basic authentication over https.
    • Pro: requires nothing on the client side
    • Con: may not be entirely secure
  • Upon authentication, the server issues a token (e.g. JWT or some other token) which is stored as a Cookie with "HttpOnly"+"Secure" flags to prevent it from being stolen via XSS. To also prevent XSRF/CSRF, the server would issue a XSRF-token which the client (app) needs to attach to prove the origin of the request
    • Pro: seems to be very secure
    • Con: requires JavaScript and Cookies. Users disabling one or the other are locked out
  • Upon authentication, the server issues a token (e.g. JWT or some other token) which is stored in LocalStorage and the client app needs to attach it to every request. Need to make sure that no XSS attack is possible to prevent the token from being stolen.
    • Pro: secure if XSS can be prevented. Does not require Cookies.
    • Con: requires a JavaScript app to run and store and attach the token. Users disabling JavaScript are locked out.

Overall, I have not seen a secure strategy that works well without JavaScript. Am I missing something? Would it be ok to have the web-app (JavaScript) client use a Token+LocalStorage or Cookie strategy and fallback to Basic Auth for the HTML-only client? Any other ideas?

  • Have you considered client certificates, or are browsers that you consider restricted unable to use client certificates? They do not require JavaScript and are entirely part of the TLS protocol (so even e.g. plain TLS libraries can support it). – forest Mar 14 '18 at 5:49
  • Actually yes - for some users. The problem is, that the website is intended for corporate users from different external organizations. Some organizations will support JavaScript+Cookies, while others (one in particular) has everything locked down. I am trying to strike a balance to still support users with restricted browsers while not weakening security for everyone else. – user1211286 Mar 14 '18 at 7:39

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.