3 ms·

I've got Opinions and Thoughts on OAuth2 (& all those other protocols, SAML/OIDC) They all model sharing trust over to untrusted boundaries using signed messag

by kache_ 5y ago

I've got Opinions and Thoughts on OAuth2 (& all those other protocols, SAML/OIDC) They all model sharing trust over to untrusted boundaries using signed messages generated by one signing authority. There's always a client, different clients have different properties, they're trying to access a resource, and there is a privileged signatory. Lots can be learned from their specs, but please don't limit yourself to them, and don't even worry about following the spec accurately (no one really does). Just know WHY the spec is designed the way they are so that you avoid the same security pitfalls. And understand WHAT you're doing: granting signed assertions based on some user interactions Not only that, but just because it got through the IETF gauntlet doesn't mean they don't have problems. These specs slide around like crazy. My OAuth is different from your OAuth. The antidote? Just write Good Docs and provide good libraries for your integration path. A smart kid in a vacuum solving the same problem OAuth solves will come up with OAuth. Try to emulate that smart kid. And understand why certain concessions are made on the protocols you're taking inspiration from because you might actually not need to make those concessions This stuff hasn't been fully figured out, so push the needle forward and don't be limited by the past. All protocols are incorrect given a large enough time span.

mooreds 5y ago
> A smart kid in a vacuum solving the same problem OAuth solves will come up with OAuth. Try to emulate that smart kid. And understand why certain concessions are made on the protocols you're taking inspiration from because you might actually not need to make those concessions. I have a different perspective. I work for an auth company now, but before I did, I didn't want to think about this at all. I wanted to get some code shipped and build differentiating features. I agree that the IETF and other standards bodies are not perfect (there are specs that get published that never get implemented widely and standards that are implemented that are retrofitted specs). I do think that building on top of a spec is a great way to "stand on the shoulders of giants", get access to people's experience in use cases you haven't seen yet, and accelerate your development effort. Also, there are a lot of folks who've written client libraries, docs, and tutorials around OAuth that people can leverage. How many devs will have experience with your "antidote"? I dunno, but my guess is the number rounds to zero.
lijogdfljk 5y ago
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.
    - 5y ago
paxys 5y ago
A smart kid implementing encryption from scratch could come up with RSA or PKCS or EdDSA on their own. What's more likely is that they will have major holes in their implementation that decades worth of research in the area has already addressed. Similarly, while it is good to understand the various OAuth2 RFCs and why certain decisions were made, you should also just follow them instead of rolling your own auth exchange mechanism.
- kache_ 5y ago
  it would be great if everyone did "just follow them", but I haven't seen a single spec compliant implementation in all my years

by kache_ 5y ago

mooreds 5y ago

> A smart kid in a vacuum solving the same problem OAuth solves will come up with OAuth. Try to emulate that smart kid. And understand why certain concessions are made on the protocols you're taking inspiration from because you might actually not need to make those concessions. I have a different perspective. I work for an auth company now, but before I did, I didn't want to think about this at all. I wanted to get some code shipped and build differentiating features. I agree that the IETF and other standards bodies are not perfect (there are specs that get published that never get implemented widely and standards that are implemented that are retrofitted specs). I do think that building on top of a spec is a great way to "stand on the shoulders of giants", get access to people's experience in use cases you haven't seen yet, and accelerate your development effort. Also, there are a lot of folks who've written client libraries, docs, and tutorials around OAuth that people can leverage. How many devs will have experience with your "antidote"? I dunno, but my guess is the number rounds to zero.

lijogdfljk 5y ago

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.
  - 5y ago

paxys 5y ago

A smart kid implementing encryption from scratch could come up with RSA or PKCS or EdDSA on their own. What's more likely is that they will have major holes in their implementation that decades worth of research in the area has already addressed. Similarly, while it is good to understand the various OAuth2 RFCs and why certain decisions were made, you should also just follow them instead of rolling your own auth exchange mechanism.

kache_ 5y ago
it would be great if everyone did "just follow them", but I haven't seen a single spec compliant implementation in all my years