SPA best practices for authentication and session management

Question

When building SPA style applications using frameworks like Angular  Ember  React  etc  what do people believe to be some best practices for authentication and session management  I can think of a couple of ways of considering approaching the problem   Treat it no differently than authentication with a regular web application assuming the API and and UI have the same origin domain  This would likely involve having a session cookie  server side session storage and probably some session API endpoint that the authenticated web UI can hit to get current user information to help with personalization or possibly even determining roles abilities on the client side  The server would still enforce rules protecting access to data of course  the UI would just use this information to customize the experience   Treat it like any third-party client using a public API and authenticate with some sort of token system similar to OAuth  This token mechanism would used by the client UI to authenticate each and every request made to the server API    I m not really much of an expert here but  1 seems to be completely sufficient for the vast majority of cases  but I d really like to hear some more experienced opinions

User · Answer

I would go for the second  the token system   Did you know about ember-auth or ember-simple-auth  They both use the token based system  like ember-simple-auth states      A lightweight and unobtrusive library for implementing token based   authentication in Ember js applications    http   ember-simple-auth simplabs com   They have session management  and are easy to plug into existing projects too   There is also an Ember App Kit example version of ember-simple-auth  Working example of ember-app-kit using ember-simple-auth for OAuth2 authentication

User · Answer

You can increase security in authentication process by using JWT  JSON Web Tokens  and SSL HTTPS   The Basic Auth   Session ID can be stolen via    MITM attack  Man-In-The-Middle  - without SSL HTTPS An intruder gaining access to a user s computer XSS   By using JWT you re encrypting the user s authentication details and storing in the client  and sending it along with every request to the API  where the server API validates the token  It can t be decrypted read without the private key  which the server API stores secretly  Read update   The new  more secure  flow would be   Login   User logs in and sends login credentials to API  over SSL HTTPS  API receives login credentials If valid    Register a new session in the database Read update Encrypt User ID  Session ID  IP address  timestamp  etc  in a JWT with a private key   API sends the JWT token back to the client  over SSL HTTPS  Client receives the JWT token and stores in localStorage cookie   Every request to API   User sends a HTTP request to API  over SSL HTTPS  with the stored JWT token in the HTTP header API reads HTTP header and decrypts JWT token with its private key API validates the JWT token  matches the IP address from the HTTP request with the one in the JWT token and checks if session has expired If valid    Return response with requested content  If invalid    Throw exception  403   401  Flag intrusion in the system Send a warning email to the user     Updated 30 07 15   JWT payload claims can actually be read without the private key  secret  and it s not secure to store it in localStorage  I m sorry about these false statements  However they seem to be working on a JWE standard  JSON Web Encryption    I implemented this by storing claims  userID  exp  in a JWT  signed it with a private key  secret  the API backend only knows about and stored it as a secure HttpOnly cookie on the client  That way it cannot be read via XSS and cannot be manipulated  otherwise the JWT fails signature verification  Also by using a secure HttpOnly cookie  you re making sure that the cookie is sent only via HTTP requests  not accessible to script  and only sent via secure connection  HTTPS    Updated 17 07 16   JWTs are by nature stateless  That means they invalidate expire themselves  By adding the SessionID in the token s claims you re making it stateful  because its validity doesn t now only depend on signature verification and expiry date  it also depends on the session state on the server  However the upside is you can invalidate tokens sessions easily  which you couldn t before with stateless JWTs

User · Answer

This question has been addressed  in a slightly different form  at length  here    RESTful Authentication  But this addresses it from the server-side  Let s look at this from the client-side  Before we do that  though  there s an important prelude   Javascript Crypto is Hopeless  Matasano s article on this is famous  but the lessons contained therein are pretty important   https   www nccgroup trust us about-us newsroom-and-events blog 2011 august javascript-cryptography-considered-harmful   To summarize     A man-in-the-middle attack can trivially replace your crypto code with  lt script gt  function hash algorithm password   lol nope send it to me instead password     lt  script gt  A man-in-the-middle attack is trivial against a page that serves any resource over a non-SSL connection  Once you have SSL  you re using real crypto anyways    And to add a corollary of my own    A successful XSS attack can result in an attacker executing code on your client s browser  even if you re using SSL - so even if you ve got every hatch battened down  your browser crypto can still fail if your attacker finds a way to execute any javascript code on someone else s browser     This renders a lot of RESTful authentication schemes impossible or silly if you re intending to use a JavaScript client  Let s look    HTTP Basic Auth  First and foremost  HTTP Basic Auth  The simplest of schemes  simply pass a name and password with every request   This  of course  absolutely requires SSL  because you re passing a Base64  reversibly  encoded name and password with every request  Anybody listening on the line could extract username and password trivially  Most of the  Basic Auth is insecure  arguments come from a place of  Basic Auth over HTTP  which is an awful idea    The browser provides baked-in HTTP Basic Auth support  but it is ugly as sin and you probably shouldn t use it for your app  The alternative  though  is to stash username and password in JavaScript   This is the most RESTful solution  The server requires no knowledge of state whatsoever and authenticates every individual interaction with the user  Some REST enthusiasts  mostly strawmen  insist that maintaining any sort of state is heresy and will froth at the mouth if you think of any other authentication method  There are theoretical benefits to this sort of standards-compliance - it s supported by Apache out of the box - you could store your objects as files in folders protected by  htaccess files if your heart desired   The problem  You are caching on the client-side a username and password  This gives evil ru a better crack at it - even the most basic of XSS vulnerabilities could result in the client beaming his username and password to an evil server  You could try to alleviate this risk by hashing and salting the password  but remember  JavaScript Crypto is Hopeless  You could alleviate this risk by leaving it up to the Browser s Basic Auth support  but   ugly as sin  as mentioned earlier    HTTP Digest Auth  Is Digest authentication possible with jQuery   A more  secure  auth  this is a request response hash challenge  Except JavaScript Crypto is Hopeless  so it only works over SSL and you still have to cache the username and password on the client side  making it more complicated than HTTP Basic Auth but no more secure   Query Authentication with Additional Signature Parameters   Another more  secure  auth  where you encrypt your parameters with nonce and timing data  to protect against repeat and timing attacks  and send the  One of the best examples of this is the OAuth 1 0 protocol  which is  as far as I know  a pretty stonking way to implement authentication on a REST server    http   tools ietf org html rfc5849  Oh  but there aren t any OAuth 1 0 clients for JavaScript  Why     JavaScript Crypto is Hopeless  remember  JavaScript can t participate in OAuth 1 0 without SSL  and you still have to store the client s username and password locally - which puts this in the same category as Digest Auth - it s more complicated than HTTP Basic Auth but it s no more secure    Token  The user sends a username and password  and in exchange gets a token that can be used to authenticate requests    This is marginally more secure than HTTP Basic Auth  because as soon as the username password transaction is complete you can discard the sensitive data  It s also less RESTful  as tokens constitute  state  and make the server implementation more complicated    SSL Still  The rub though  is that you still have to send that initial username and password to get a token  Sensitive information still touches your compromisable JavaScript    To protect your user s credentials  you still need to keep attackers out of your JavaScript  and you still need to send a username and password over the wire  SSL Required   Token Expiry  It s common to enforce token policies like  hey  when this token has been around too long  discard it and make the user authenticate again   or  I m pretty sure that the only IP address allowed to use this token is XXX XXX XXX XXX   Many of these policies are pretty good ideas   Firesheeping  However  using a token Without SSL is still vulnerable to an attack called  sidejacking   http   codebutler github io firesheep   The attacker doesn t get your user s credentials  but they can still pretend to be your user  which can be pretty bad    tl dr  Sending unencrypted tokens over the wire means that attackers can easily nab those tokens and pretend to be your user  FireSheep is a program that makes this very easy    A Separate  More Secure Zone  The larger the application that you re running  the harder it is to absolutely ensure that they won t be able to inject some code that changes how you process sensitive data  Do you absolutely trust your CDN  Your advertisers  Your own code base    Common for credit card details and less common for username and password - some implementers keep  sensitive data entry  on a separate page from the rest of their application  a page that can be tightly controlled and locked down as best as possible  preferably one that is difficult to phish users with    Cookie  just means Token   It is possible  and common  to put the authentication token in a cookie  This doesn t change any of the properties of auth with the token  it s more of a convenience thing  All of the previous arguments still apply    Session  still just means Token   Session Auth is just Token authentication  but with a few differences that make it seem like a slightly different thing     Users start with an unauthenticated token  The backend maintains a  state  object that is tied to a user s token  The token is provided in a cookie  The application environment abstracts the details away from you    Aside from that  though  it s no different from Token Auth  really   This wanders even further from a RESTful implementation - with state objects you re going further and further down the path of plain ol  RPC on a stateful server     OAuth 2 0  OAuth 2 0 looks at the problem of  How does Software A give Software B access to User X s data without Software B having access to User X s login credentials    The implementation is very much just a standard way for a user to get a token  and then for a third party service to go  yep  this user and this token match  and you can get some of their data from us now     Fundamentally  though  OAuth 2 0 is just a token protocol  It exhibits the same properties as other token protocols - you still need SSL to protect those tokens - it just changes up how those tokens are generated   There are two ways that OAuth 2 0 can help you     Providing Authentication Information to Others  Getting Authentication Information from Others   But when it comes down to it  you re just    using tokens    Back to your question  So  the question that you re asking is  should I store my token in a cookie and have my environment s automatic session management take care of the details  or should I store my token in Javascript and handle those details myself     And the answer is  do whatever makes you happy    The thing about automatic session management  though  is that there s a lot of magic happening behind the scenes for you  Often it s nicer to be in control of those details yourself    I am 21 so SSL is yes  The other answer is  Use https for everything or brigands will steal your users  passwords and tokens

[security] SPA best practices for authentication and session management

Examples related to security

Examples related to angularjs

Examples related to authentication

Examples related to ember.js

Examples related to single-page-application