| 8 Mar 2024 |
 raitobezarius | that doesn't change the fact there's no alternative to SAML and there's a sensible path to SAML implementation | 18:01:12 |
| raitobezarius | so maybe firstyear will expand his section on why SAML is bad and I hope it's not because people in the enterprise ecosystem doesn't know how to do canonical document formats | 18:02:01 |
| raitobezarius | because, if that's the argument, I hope people applies it to their own software. | 18:02:25 |
| 9 Mar 2024 |
 hexa | In reply to @raitobezarius:matrix.org
oauth2 is not an alternative right, saml is a concept that separate identity and service providers quite neatly, but why would you rule out oauth2? | 01:35:25 |
| raitobezarius | because OAuth2 is an authorization protocol | 01:36:41 |
| raitobezarius | OpenID Connect is an authentication mechanism on the top of it | 01:36:51 |
| hexa | so? | 01:37:30 |
| hexa | that is just stating facts, not requirements it misses | 01:37:53 |
| raitobezarius | First thing is that you want to build protocols on data formats that have certain properties, like normal forms, JSON does not have normal forms (except for JCS) to be clear and this is the source of a lot of issues when it comes to produce signatures (and hence the source of a lot of malleability issues. So the statut quo on SAML bugs vs OIDC bugs is similar in the sense both can suffer from malleability implementation issues w.r.t. to the canonical format.
Then, SAML possess a bunch of features that OIDC ecosystem still does not see, e.g. Federation. But, it does have a significant amount of RFC to introduce a lot of surface, which means that the SAML "weaknesses" are again present in OIDC ecosystem:
https://datatracker.ietf.org/doc/html/rfc7636 https://datatracker.ietf.org/doc/html/rfc6819 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics https://datatracker.ietf.org/doc/html/rfc9068 https://datatracker.ietf.org/doc/html/rfc8252 https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps https://datatracker.ietf.org/doc/html/rfc8628 https://datatracker.ietf.org/doc/html/rfc8414 https://datatracker.ietf.org/doc/html/rfc8414 https://datatracker.ietf.org/doc/html/rfc7591 https://datatracker.ietf.org/doc/html/rfc7592 https://datatracker.ietf.org/doc/html/rfc9126 https://datatracker.ietf.org/doc/html/rfc8705 https://datatracker.ietf.org/doc/html/rfc9101 https://datatracker.ietf.org/doc/html/rfc7521 https://datatracker.ietf.org/doc/html/rfc7522 (this one is quite fun) https://datatracker.ietf.org/doc/html/rfc7636 https://datatracker.ietf.org/doc/html/rfc7009 https://datatracker.ietf.org/doc/html/rfc7662
And things like https://openid.net/specs/openid-federation-1_0.html are still at the draft phase | 01:46:25 |
| raitobezarius | There's even a longer list of RFCs in development by governement entities, financial institutions, all spawning off their own vision of OIDC | 01:47:31 |
| raitobezarius | Making this whole ecosystem even more complicated to deal with whereas SAML has provided solid "time tested" primitives (for those who implemented them correctly, I don't reject the arguments you provided on the actual in the wild implementation issues, but those are of the same flavor of XML deserialization bugs in Java tbh) | 01:48:31 |
| raitobezarius | An interesting example of missing requirement in OIDC is the session management problem | 01:48:49 |
| hexa | For me personally federation is not a strong use case | 01:48:54 |
| hexa | not even for my workplace | 01:49:12 |
| raitobezarius | Sure, but, well, that's a completely valid usecase and there's others | 01:49:36 |
| hexa | the only reasonable deployment I've seen is for universities | 01:50:06 |
| raitobezarius | Well, governments or so-called dataspaces need this sort of stuff too | 01:50:21 |
| hexa | makes sense | 01:50:28 |
| raitobezarius | Even in the same organization, when there's multiple authorities with separated infrastructure, federation makes a bunch of political stuff easier | 01:50:53 |
| raitobezarius | Because you don't get to enforce / assert LDAP ownership | 01:51:04 |
| raitobezarius | First party native application login via OIDC is being removed in https://oauth.net/2.1/ | 01:51:34 |
| raitobezarius | Which means that you always have to pop up that web page when logging in via OIDC in any native app | 01:51:49 |
| raitobezarius | How to log out users in OIDC is very interesting (again a consequence of authorization protocol being used for auth) | 01:52:25 |
| raitobezarius | so there's this spec https://openid.net/specs/openid-connect-frontchannel-1_0.html | 01:52:29 |
| raitobezarius | which almost no one implement | 01:52:32 |
| raitobezarius | which means that for example if you login to circleci via github, log out from github, you are still logged in in circleci | 01:52:44 |
| raitobezarius | Auth0 who handles a lot of stuff for you has very fun documentation on it: https://auth0.com/docs/manage-users/sessions/session-layers#session-logout | 01:53:05 |
| raitobezarius | They have always 3 sessions to manage this sort of stuff | 01:53:15 |
| hexa | yeah, that is a can of worms, agreed | 01:53:25 |
| hexa | but does that really justify the added complexity for saml? | 01:53:42 |
