4 ms·

As an Oauth2 hater, I consider this protocol cursed, mainly due to how hard it is to read through all the specs and have a useful understanding of what one shou

by er4hn 2y ago

As an Oauth2 hater, I consider this protocol cursed, mainly due to how hard it is to read through all the specs and have a useful understanding of what one should do with it. Reading the OIDC spec, where they define authN in terms of authZ, lets me experience what a stroke must feel like.

paulddraper 2y ago
Is SAML any better?
- andrewstuart2 2y ago
  Absolutely not. Read the specs [0] there as well if you truly want to know. XML canonicalization is a special kind of hell that I've done once and wish to never do again. And the enveloped signatures of xmldsig are also pretty complicated to get right. And it's a wild west as to how the specs are implemented on RPs and IDPs alike (more so, in my experience, than OIDC by a long shot). [0] https://www.oasis-open.org/standard/saml/ https://www.oasis-open.org/standard/saml/ or https://saml.xml.org/saml-specifications https://saml.xml.org/saml-specifications
  - paulddraper 2y ago
    (I know, agreed. Rhetorical.)
- tptacek 2y ago
  SAML is much, much worse than OIDC. https://news.ycombinator.com/item?id=28080553 https://news.ycombinator.com/item?id=28080553
- jcmfernandes 2y ago
  Give it a try and try to come back with your sanity intact. I dare you :) It's mess.
  - tolien 2y ago
    Having just updated a project to use a newer version of the OpenSAML libs, this x1000. How something so fundamental can be so badly implemented (and documented!) is just mind-blowing.
- jrochkind1 2y ago
  No. I think SAML(/Shibboleth) was a big influence to OAuth2 (?) and is probably the source of most of what ails OAuth2.
sebazzz 2y ago
I actually find it very readable. It was at least readable enough so I could implement an OAuth2 client from scratch in C# as a student. However after years I still don't understand the technical differences between OpenID Connect and OAuth2. Can a OAuth2 client connect to a OpenID Connect server?
- ForHackernews 2y ago
  OpenID Connect is an extension to OAuth2 and a strict superset of it. All OpenID Connect servers are OAuth2 authorization servers - but not the inverse. OAuth2 technically only offers "authorization" (granting access to do something), but OpenID Connect adds an "authentication" (who is getting this access?) layer on top of OAuth2 by returning an id_token alongside the authorization_token.
unscaled 2y ago
Open ID Connect is not OAuth. It is not done as part of the IETF, and the OpenID Foundation seems to have slightly lower standards for specs. For instance, specs can be updated with errata sets that go as far as as introducing significant changes in the behavior without changing the version number and then do URL is just magically switched to the new document ("incorporating errata set N") without warning. And to top it off, there is no changelog to be found (or at least I couldn't find it). The original OAuth 2 RFC is a very easy read and it's clearer than most specs out there. It's certainly far easier to read than any W3C spec. I think the main issue is that there are too many specs that have been added over the years, and you need to know the right ones to implement. Some specs should be mandatory (like Bearer Token Usage, PKCE, OAuth for Native Apps and Current Best Practice[1] and Browser-based Apps[2] when they come out of draft). Some are useful only for certain use cases (Device Authorization Grant, Token Inspection Endpoint and Token Exchange). Some specs are horrible abominations that would hopefully never be implemented (I'm looking at you RFC 9101 JWT-Secured Authorization Request). The good news is that OAuth 2.1 incorporates some of the best RFCs I've mentioned into the core RFC. This would help make OAuth simpler by having one document to point out to. I hope it comes out soon, since at this point I still have to fight with people who think that using the Password Grant is a great idea and have no idea why they should implement PKCE or CSRF protection. [1] https://oauth.net/2/oauth-best-practice/ https://oauth.net/2/oauth-best-practice/ [2] https://oauth.net/2/browser-based-apps/ https://oauth.net/2/browser-based-apps/
- adeptima 2y ago
  > Some specs should be mandatory 100% agree OpenID Foundation seems took a path of making "profiles" like FAPI rather consolidation and enforcing the best practices and depricating the bad. FAPI (Financial-grade API Security Profile 1.0) https://openid.net/specs/openid-financial-api-part-1-1_0.html https://openid.net/specs/openid-financial-api-part-1-1_0.htm... I hope the community will combine it all at some point and add specifications for proper policy and resources management too by looking at the full lifecycle of modern applications.
  - unscaled 2y ago
    Hopefully, when OAuth 2.1 is released, OpenID Connect will be updated to be based on OAuth 2.1. This would make some of the useful advice in FAPI (like PKCE) mandatory. A lot of the FAPI stuff that is not included in OAuth 2.1 or the OAuth BCP is just over-engineering by wanabee cryptographers, bad advice, or at least useless advice. Knowing the OpenID foundation, this could be yet another undocumented errata set released, but we can still dream of a better world, can't we? In a better world, instead of "Use 2048 bit RSA keys" the spec will say "Don't use RSA ever." The advanced FAPI has even more directly bad advice, as requiring PS256 and ES256. Now, these are not so bad as the common RS256 (RSA with PKCSv1.5 padding), but they are still bad algorithms. The only good asymmetric algorithm defined in JWS is EdDSA, which just like that, is forbidden by OIDC FAPI. So I'm quite happy FAPI is just a profile that would mostly be ignored.
stuaxo 2y ago
Some of the worst times I have had in projects are when I've had to add oauth2.
- hi_hi 2y ago
  Ha, I'm just reading this after tearing my hair out after trying to get a basic omniauth google login working in Rails. I was hitting CORS issues, for hours. I'm new to rails, but had read how productive it makes you. Well, thanks to one of their productivity features (Turbo) I was ready to throw the whole thing out. Yes, I know, this wasn't an oauth2 issue directly. /rant :-)

by er4hn 2y ago

paulddraper 2y ago

Is SAML any better?

andrewstuart2 2y ago
Absolutely not. Read the specs [0] there as well if you truly want to know. XML canonicalization is a special kind of hell that I've done once and wish to never do again. And the enveloped signatures of xmldsig are also pretty complicated to get right. And it's a wild west as to how the specs are implemented on RPs and IDPs alike (more so, in my experience, than OIDC by a long shot). [0] https://www.oasis-open.org/standard/saml/ https://www.oasis-open.org/standard/saml/ or https://saml.xml.org/saml-specifications https://saml.xml.org/saml-specifications
- paulddraper 2y ago
  (I know, agreed. Rhetorical.)
tptacek 2y ago
SAML is much, much worse than OIDC. https://news.ycombinator.com/item?id=28080553 https://news.ycombinator.com/item?id=28080553
jcmfernandes 2y ago
Give it a try and try to come back with your sanity intact. I dare you :) It's mess.
- tolien 2y ago
  Having just updated a project to use a newer version of the OpenSAML libs, this x1000. How something so fundamental can be so badly implemented (and documented!) is just mind-blowing.
jrochkind1 2y ago
No. I think SAML(/Shibboleth) was a big influence to OAuth2 (?) and is probably the source of most of what ails OAuth2.

sebazzz 2y ago

I actually find it very readable. It was at least readable enough so I could implement an OAuth2 client from scratch in C# as a student. However after years I still don't understand the technical differences between OpenID Connect and OAuth2. Can a OAuth2 client connect to a OpenID Connect server?

ForHackernews 2y ago
OpenID Connect is an extension to OAuth2 and a strict superset of it. All OpenID Connect servers are OAuth2 authorization servers - but not the inverse. OAuth2 technically only offers "authorization" (granting access to do something), but OpenID Connect adds an "authentication" (who is getting this access?) layer on top of OAuth2 by returning an id_token alongside the authorization_token.

unscaled 2y ago

Open ID Connect is not OAuth. It is not done as part of the IETF, and the OpenID Foundation seems to have slightly lower standards for specs. For instance, specs can be updated with errata sets that go as far as as introducing significant changes in the behavior without changing the version number and then do URL is just magically switched to the new document ("incorporating errata set N") without warning. And to top it off, there is no changelog to be found (or at least I couldn't find it). The original OAuth 2 RFC is a very easy read and it's clearer than most specs out there. It's certainly far easier to read than any W3C spec. I think the main issue is that there are too many specs that have been added over the years, and you need to know the right ones to implement. Some specs should be mandatory (like Bearer Token Usage, PKCE, OAuth for Native Apps and Current Best Practice[1] and Browser-based Apps[2] when they come out of draft). Some are useful only for certain use cases (Device Authorization Grant, Token Inspection Endpoint and Token Exchange). Some specs are horrible abominations that would hopefully never be implemented (I'm looking at you RFC 9101 JWT-Secured Authorization Request). The good news is that OAuth 2.1 incorporates some of the best RFCs I've mentioned into the core RFC. This would help make OAuth simpler by having one document to point out to. I hope it comes out soon, since at this point I still have to fight with people who think that using the Password Grant is a great idea and have no idea why they should implement PKCE or CSRF protection. [1] https://oauth.net/2/oauth-best-practice/ https://oauth.net/2/oauth-best-practice/ [2] https://oauth.net/2/browser-based-apps/ https://oauth.net/2/browser-based-apps/

adeptima 2y ago
> Some specs should be mandatory 100% agree OpenID Foundation seems took a path of making "profiles" like FAPI rather consolidation and enforcing the best practices and depricating the bad. FAPI (Financial-grade API Security Profile 1.0) https://openid.net/specs/openid-financial-api-part-1-1_0.html https://openid.net/specs/openid-financial-api-part-1-1_0.htm... I hope the community will combine it all at some point and add specifications for proper policy and resources management too by looking at the full lifecycle of modern applications.
- unscaled 2y ago
  Hopefully, when OAuth 2.1 is released, OpenID Connect will be updated to be based on OAuth 2.1. This would make some of the useful advice in FAPI (like PKCE) mandatory. A lot of the FAPI stuff that is not included in OAuth 2.1 or the OAuth BCP is just over-engineering by wanabee cryptographers, bad advice, or at least useless advice. Knowing the OpenID foundation, this could be yet another undocumented errata set released, but we can still dream of a better world, can't we? In a better world, instead of "Use 2048 bit RSA keys" the spec will say "Don't use RSA ever." The advanced FAPI has even more directly bad advice, as requiring PS256 and ES256. Now, these are not so bad as the common RS256 (RSA with PKCSv1.5 padding), but they are still bad algorithms. The only good asymmetric algorithm defined in JWS is EdDSA, which just like that, is forbidden by OIDC FAPI. So I'm quite happy FAPI is just a profile that would mostly be ignored.

stuaxo 2y ago

Some of the worst times I have had in projects are when I've had to add oauth2.

hi_hi 2y ago
Ha, I'm just reading this after tearing my hair out after trying to get a basic omniauth google login working in Rails. I was hitting CORS issues, for hours. I'm new to rails, but had read how productive it makes you. Well, thanks to one of their productivity features (Turbo) I was ready to throw the whole thing out. Yes, I know, this wasn't an oauth2 issue directly. /rant :-)