4 ms·

I don't think this is a good critique of OAuth at all. First of all, the majority of complaints aren't even about OAuth, they're about (a specific implementati

I don't think this is a good critique of OAuth at all. First of all, the majority of complaints aren't even about OAuth, they're about (a specific implementation of consuming) OpenID Connect, which it doesn't seem like the author realises he's using. JWTs aren't in OAuth 2.0. If the author had realised this, surely when looking for libraries to assist with the project he would've looked for an OIDC or JWT library instead of something specific to Google. There are plenty of library recommendations on the JWT website[1], including .NET. It's not like OAuth 2.0 or OIDC are trivial to use, but these aren't easy problems to solve. OpenID Connect is young, and there's still a lot lacking in terms of library support and (probably more importantly) documentation. I'd rather deal with the rough edges of OIDC than use SAML any day of the week. [1]: http://jwt.io http://jwt.io

nickbauman 11y ago
Agree. SAML is crazy complicated.
- notwhereyouare 11y ago
  Yep. Spent basically 2 months trying to implement saml manually. We had kinda a working implementation for something else. Tried to use it. Didn't work. Ended up finding a solution that somebody published. Modified and got working for my situation. It sucked and put me really behind schedule. Doesn't matter. The other members of the project were ever further behind
- volkadav 11y ago
  The entire spec, yes, is big, but the part you actually need is not that complicated. I implemented the IdP for the new york times (there's quite a bit of third party shit plugged into the nytimes.com web experience that we wanted to be transparent to users) in a few weeks as I recall, and I'm not some coding super-genius. (It was kinda hacktified and minimalistic, but it worked at scale. ¯\_(ツ)_/¯) Most of our counter-parties were up and running in a week or so. Compared to the abysmal quagmire that was our ecommerce code, SAML implementation was a total milk run.
- X-Istence 11y ago
  The worst part is that SAML doesn't seem to be adequately documented, and figuring out how to do various flows against it (such as allowing a user to auth into a web app, and a third party API such as OpenStack) is almost impossible to figure out.
- jordache 11y ago
  why would you need to understand the entire SAML spec? Are you implementing a custom idp system? Assuming you are using a well established authentication provider that has built in support for SAML? In that case it's simply a matter of configuration....
- SCHiM 11y ago
  Not only is it complicated, the lack of documentation and the leaky XML libraries that abound ensure that whoever ends up implementing SAML are prone to make security mistakes. I've audited two systems that used SAML to authenticate their users, both times I found XXE vulnerabilities that let me read files from their servers with the permissions of the webserver process.
Aeolun 11y ago
Summary of crazy terms in this post: OAuth, OpenID Connect, JWT, OAuth 2.0, OIDC, SAML. I know what what only one of these means (OAuth), and the only thing it means to me is I'm in for a world of hurt. I agree with the author, regardless of whether his terms were correct. It'd be nice to have something safe AND simple to authenticate people with.
- broodbucket 11y ago
  I agree that setting up federated identity isn't as easy as you'd like, but that doesn't mean saying "OAuth sucks!" is okay when a) it's OpenID Connect in this case and b) he's not really talking about anything that's in the spec, it's setting up with one provider with the wrong tools to do so. There are safe AND simple systems, and you pay per user or per authentication to those companies that provide them. It's security, there's no one-click solution, you've gotta do it properly (which can include paying someone to do it properly for you). Google's OpenID Connect documentation [1] is pretty good, and for the steps that involve code in your application, there's very likely a library [2][3] that does it for you. It'd probably take you a day to put something together without existing knowledge, and then you've got secure federated login using an open industry standard that you can easily extend to add other identity providers. [1] https://developers.google.com/identity/protocols/OpenIDConnect?hl=en https://developers.google.com/identity/protocols/OpenIDConne... [2] http://openid.net/developers/libraries/ http://openid.net/developers/libraries/ [3] http://jwt.io http://jwt.io
- hohenheim 11y ago
  Your requirement is unrealistic. "safe AND simple" can not be if the problem is inherently complex. Security is complex. Sure there could be third party providers that take care of the complexity and provide a service for you, but then is it safe? You could attempt to do it yourself, but then you loose the simplicity and still you don't know if it is safe.
  - spronkey 11y ago
    Well, to be fair, it wouldn't be all that complex if we just had one standard instead of many many many to learn. I don't find OAuth2 as implemented by most all that complex, and I didn't really find OAuth1 all that bad either. The web UI for persona, on the other hand... Who on earth thought it was a good idea to have a two step for username THEN password!?

nickbauman 11y ago

Agree. SAML is crazy complicated.

notwhereyouare 11y ago
Yep. Spent basically 2 months trying to implement saml manually. We had kinda a working implementation for something else. Tried to use it. Didn't work. Ended up finding a solution that somebody published. Modified and got working for my situation. It sucked and put me really behind schedule. Doesn't matter. The other members of the project were ever further behind
volkadav 11y ago
The entire spec, yes, is big, but the part you actually need is not that complicated. I implemented the IdP for the new york times (there's quite a bit of third party shit plugged into the nytimes.com web experience that we wanted to be transparent to users) in a few weeks as I recall, and I'm not some coding super-genius. (It was kinda hacktified and minimalistic, but it worked at scale. ¯\_(ツ)_/¯) Most of our counter-parties were up and running in a week or so. Compared to the abysmal quagmire that was our ecommerce code, SAML implementation was a total milk run.
X-Istence 11y ago
The worst part is that SAML doesn't seem to be adequately documented, and figuring out how to do various flows against it (such as allowing a user to auth into a web app, and a third party API such as OpenStack) is almost impossible to figure out.
jordache 11y ago
why would you need to understand the entire SAML spec? Are you implementing a custom idp system? Assuming you are using a well established authentication provider that has built in support for SAML? In that case it's simply a matter of configuration....
SCHiM 11y ago
Not only is it complicated, the lack of documentation and the leaky XML libraries that abound ensure that whoever ends up implementing SAML are prone to make security mistakes. I've audited two systems that used SAML to authenticate their users, both times I found XXE vulnerabilities that let me read files from their servers with the permissions of the webserver process.

Aeolun 11y ago

Summary of crazy terms in this post: OAuth, OpenID Connect, JWT, OAuth 2.0, OIDC, SAML. I know what what only one of these means (OAuth), and the only thing it means to me is I'm in for a world of hurt. I agree with the author, regardless of whether his terms were correct. It'd be nice to have something safe AND simple to authenticate people with.

broodbucket 11y ago
I agree that setting up federated identity isn't as easy as you'd like, but that doesn't mean saying "OAuth sucks!" is okay when a) it's OpenID Connect in this case and b) he's not really talking about anything that's in the spec, it's setting up with one provider with the wrong tools to do so. There are safe AND simple systems, and you pay per user or per authentication to those companies that provide them. It's security, there's no one-click solution, you've gotta do it properly (which can include paying someone to do it properly for you). Google's OpenID Connect documentation [1] is pretty good, and for the steps that involve code in your application, there's very likely a library [2][3] that does it for you. It'd probably take you a day to put something together without existing knowledge, and then you've got secure federated login using an open industry standard that you can easily extend to add other identity providers. [1] https://developers.google.com/identity/protocols/OpenIDConnect?hl=en https://developers.google.com/identity/protocols/OpenIDConne... [2] http://openid.net/developers/libraries/ http://openid.net/developers/libraries/ [3] http://jwt.io http://jwt.io
hohenheim 11y ago
Your requirement is unrealistic. "safe AND simple" can not be if the problem is inherently complex. Security is complex. Sure there could be third party providers that take care of the complexity and provide a service for you, but then is it safe? You could attempt to do it yourself, but then you loose the simplicity and still you don't know if it is safe.
- spronkey 11y ago
  Well, to be fair, it wouldn't be all that complex if we just had one standard instead of many many many to learn. I don't find OAuth2 as implemented by most all that complex, and I didn't really find OAuth1 all that bad either. The web UI for persona, on the other hand... Who on earth thought it was a good idea to have a two step for username THEN password!?