> I recommend just keeping cookies out of the equation, that makes CSRF > issues go away which gives you a simpler implementation. >
I had the impression that cookies are still "the way things are done", and to be honest didn't really consider not using them at all. But it seems I should revise that :) > Some answers below, hope you don't mind the long answers :) > Quite the contrary, it's great to get your opinions and review! > Where possible I tried to base the impl on what's in Play, as I trust them >> to do the "right thing" >> > Well, not a bad starting point, but I imagine Play has legacy and > backwards compatibility to consider (cookies) and does server side > rendering. I'm suggesting what is right for Play might just be OK for a > green field library. > > I read about JWT, from what I understand it's kind of a combination of how >> header-based CSRF protection works and keeping the content of the cookie in >> memory only, (instead in the cookie). > > > CSRF protection is only needed because of the use of cookies or Basic Auth > where then the browser automatically attaches the authentication/cookie to > each request for a domain. If you don't have to be backwards compatible > with a cookie based client side sessions (as Play have to) then instead of > using CSRF protection you might as well do away with cookies altogether, if > you are already using header based CSRF then you actually gain simplicity. > So you would need to send the session token (in any data format really, I guess it can also be the same content as the cookie I'm constructing currently) in a custom header, and you would get CSRF protection "for free", though it would only work for AJAX requests. > With JWT you do commonly send the token as a header (Authorization: Bearer > <your jwt>). But this is not in any way mandated by JWT or JOSE (Javascript > Object Signing and Encryption). You can send a JWT as a POST body or as a > Cookie if you wish, sorry if I was misleading on that. JOSE-JWT is a data > format. > Well the signature is a hash, the optional encryption of the data is >> symmetrical. > > HMAC uses symmetrical keys. You do have a point in that a MAC is not a > digital signature > <http://crypto.stackexchange.com/questions/5646/what-are-the-differences-between-a-digital-signature-a-mac-and-a-hash>. > > To verify the HMAC you need the same secret key that was used to create it. > That means you can create a new signature for a different message. If you > have a monolithic application that is fine (like Play apps) if you have > multiple applications or multiple small services you may not wish to > distribute that key to all clients that need to verify the session. > Ah, microservices, right ;) Although I suppose it's quite common to have a single "orchestrator" service which does the whole frontend job. But of course it doesn't have to be that way. > Also, if you want to implement "remember me", I suppose you need to resort >> to cookies anyway to have some kind of persistent client-side storage? >> > > Yes browser Local Storage should fit well. The advantage of Local Storage > over cookies is again no CSRF issues. In the case of JWT a "remember me" > could just be a JWT with a long expiration. > When using Local Storage, would you still separate the "current session data" - containing the signed/encrypted user id or username (that would go to sessionStorage) and a "remember me token" (stored in localStorage) like you do with cookies? It has some nice properties, like varying access levels based on automatic/manual logins or knowing when users log in (automatically or manually). Thanks, Adam -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
