OIDC is better when using the authorization code flow because it does not only rely on cryptography while validating the token. The relying party needs to talk to the IdP. This is better from a security perspective, because past vulnerabilities have shown, that implementing the cryptography right in every relying party is challenging. You can achieve similar security with SAML when using the artifact binding.
Note: I work professionally with Keycloak and also offer reviews of OIDC and SAML implementations.
I don't think artifact binding really addresses many of the issues people are talking about when they suggest OIDC is categorically more secure than SAML.
OIDC is newer and many of the issues with SAML were addressed in the architecture. However I’m curious to hear which attack vectors you are thinking about.
A common pattern of SAML vulnerability is one that allows logins from one org access to resources of another org, which is not mitigated by trusting IdP's.
SAML is an unfortunate a necessity in most enterprise environments. There’s almost always something, usually more than one, where SAML is the only option. I do think in 2024, everyone should also offer SAML alternatives in parallel
.
Sure, but that would arise because you've followed the advice in the article.
If you're a relying party, and you want to integrate with Okta, Google, other OIDC-supporting IdPs … implement OIDC!
If you're on the RP side and you have to integrate with an IdP that only speaks SAML and not OIDC, well, then you're probably out of luck and just have to make the call: is it worth the business? Maybe it is. Then you implement SAML.
PKCE (specifically the S256 method, but that's the one that you're supposed to implement in almost all cases) is by itself a cryptographic method, but there are few points to note here:
1. PKCE relies on very simple cryptography that is hard to implement incorrectly. There is only is only one protocol defined (SHA-256), and that protocol is considered safe. Allowing the "plain" protocol in the RFC was silly, but we were lucky that the RFC writers didn't go full bonkers like they did with JWT, and started digging up ancient ciphers in case someone really wants to run PKCE on a WW2 vintage Enigma machine. In short, PKCE has no weird or old cryptography.
2. PKCE is not considered mandatory or even recommended for confidential clients prior to OAuth 2.1 (which is still a draft). It is rarely implemented in these cases.
3. You cannot use JWKS for PKCE. I believe you are confusing PKCE with the ID Token, but the GP was specifically talking about the Authorization Code flow, where the ID Token doesn't really matter. If you're using that flow an unfortunate piece of over-engineered industrial waste[1], but if you're using the Authorization Code flow it doesn't matter: even if the ID Token is completely broken, it cannot hurt you, since you must have a correct authorization code to get it in the first place.
4. Even if PKCE itself gets broken somehow (the main risk being an IdP that allows downgrade attacks), this only makes the protocol vulnerable to CSRF on confidential clients. Only on public clients that rely on custom URL schemes (such as native apps), this can lead to a more serious exploit.
[1] Sadly, this is coming from the same people who wrote the PKCE spec. On one hand they think your system might be too constrained to support SHA-256, so we need to add the "plain" algorithm, but on the other hand, they make RSA signatures (including SHA-256!) a mandatory part of the Open ID Connect spec through this totally unnecessary token.
Interesting read. I have just setup a very similar cluster this week: 3 node bare metal cluster in a 10G mesh network. Decided for Debian, RKE2, Calico and Longhorn. Encryption is done using LUKS FDE. For Load Balancing I am using the HCloud Load Balancer (in TCP mode).
At first I had some problems with the mesh network as the CNI would only bind to a single interface. Finally solved it using a bridge, veth and isolated ports.
Initially Ubuntu 20.04, but I upgraded to 22.04. Finally got it working -- turns out a lot of things that reference `--cgroup-driver="systemd"` are doing it as if it were run in shell, which means that the quotes around "systemd" get removed by shell, and would lead to an error & ignored options.
Nothing was showing whatsoever when using 20.04, so I wonder if there were some missing dependencies somewhere there...
I'll probably write up everything I discovered at some point, there's a lot of pieces that you have to cobble together from pretty disparate sources (network plugins, config files (which!?), etc).
Software development is easy, maintenance is challenging. When your system integrates with other systems and you want to make changes, it's critical to understand the details. I doubt people without IT background should be in charge of such processes.
This can superficially sound elitist, but for what it's worth I've seen plenty of conventional programmers, for whom this is their full time job, get this wrong, or spend weeks/months doing the work necessary to get it right. It isn't about the programmers being better people or something, it's really about the idea that you can not in general take something that professionals in their wheelhouse find a hard time doing and hand it off to people doing it part-time with no experience and get the same results.
Locally we're playing with "no code" but we're very much making sure it's "leaf node" sorts of tasks, that consume other services but don't provide them.
I think no-code should probably be contextualized in the context of other professions in the business. Would you take a no-accounting solution and hand it off to the programmers? Simplify away the double-entry bookkeeping (too hard for non-accountants, which, I mean, that's not sarcasm, it's really quite close to the truth), simplify all the accounting details, and then let the programmers run the finance department? What would the expected result be? Why would it be any different if you took a no-lawyer system and handed it off to sales to try to run the legal department?
There's a place for such tools nevertheless. Expense reporting software is essentially a "no accounting" accounting tool, for instance. But you keep it carefully fenced in to where it makes sense, you don't go trying to turn your expense reporting tool into the accounting software for the whole firm. I think no code has a valid place in the business but you need to make sure you're not doing the equivalent of claiming it can run accounting for the whole business.
I drive a 2023 ID.5 for 2 months and I have not faced many issues yet. Yes, the touch interface could be a bit more responsive, but I am overall very happy with the driving experience.
I have fructose malabsorption and when I eat or drink too much of it, I get brain fog (slow reaction, dizziness etc.) for one or two days. Would be interesting to see if fructose malabsorption and Alzheimer's correlate.
I think we also have lazy evaluation, heuristics (wave-particle duality), out-of-memory killers (black holes, hawking radiation) and bandwidth limitations (speed of light).
It seems obvious, hopefully it's not going to kernel panic!
reply