4 ms·

I'm often frustrated by no clear OAuth-like system for non general auth. Ie you have a server and a clientside JS app. How do you secure it? Cookies are the obv

I'm often frustrated by no clear OAuth-like system for non general auth. Ie you have a server and a clientside JS app. How do you secure it? Cookies are the obvious thing to reach for, but in general i was never clear on exactly what the options are. What are pros and cons of various types of implementations? What are the do's and don'ts? And even if i use something i often felt i was implementing all of it (due to obscure languages choices frequently), but the specifics of the impl were often difficult to find. It's embarrassing to say but auth has always confused me. And of course managers always instantly say "Just use OAuth" -_-

mooreds 5y ago
> you have a server and a clientside JS app. How do you secure it? I'd love to hear what others have to say, but I'd suggest encrypted session cookies. This is what some frameworks support out of the box (rails has docs here: https://guides.rubyonrails.org/security.html#sessions https://guides.rubyonrails.org/security.html#sessions ). Would store the session in an HttpOnly secure cookie. If you need to scale your server side horizontally, you'd use redis, a database or something similar for your session store. This feels like a problem usually solved at the framework level (and has been for years) so maybe that's why there are not as many "best practices" docs around? This OWASP document may be a useful read too: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...
- lijogdfljk 5y ago
  Appreciate the link. I also like encrypted cookies. I've not used them before, but i was really tempted because .. well, they seem an elegant low-cost way to achieve it.. iirc i was a bit unsure how to avoid any pitfalls with the encryption side of things though. Ie i don't want to allow encryption to bypass security because i chose/made a bade encryption method. Really depends on how general purpose the encryption for the cookies are. If it's very general then i suppose i can take any encryption library, but even many of those are notorious for footguns heh.
  - mooreds 5y ago
    I would definitely use a framework if at all possible, but symmetric encryption where the key stays on the server side shouldn't be too big a footgun.

mooreds 5y ago

> you have a server and a clientside JS app. How do you secure it? I'd love to hear what others have to say, but I'd suggest encrypted session cookies. This is what some frameworks support out of the box (rails has docs here: https://guides.rubyonrails.org/security.html#sessions https://guides.rubyonrails.org/security.html#sessions ). Would store the session in an HttpOnly secure cookie. If you need to scale your server side horizontally, you'd use redis, a database or something similar for your session store. This feels like a problem usually solved at the framework level (and has been for years) so maybe that's why there are not as many "best practices" docs around? This OWASP document may be a useful read too: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...

lijogdfljk 5y ago
Appreciate the link. I also like encrypted cookies. I've not used them before, but i was really tempted because .. well, they seem an elegant low-cost way to achieve it.. iirc i was a bit unsure how to avoid any pitfalls with the encryption side of things though. Ie i don't want to allow encryption to bypass security because i chose/made a bade encryption method. Really depends on how general purpose the encryption for the cookies are. If it's very general then i suppose i can take any encryption library, but even many of those are notorious for footguns heh.
- mooreds 5y ago
  I would definitely use a framework if at all possible, but symmetric encryption where the key stays on the server side shouldn't be too big a footgun.