Browser sends artifact to RP, RP fetches assertion from IdP via HTTPs, afterwards verifies the signature.
Signature verification is not implemented correctly? The attacker still needs to break HTTPS…. And then you would have a big problem anyway.
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.
When using PKCE the relying party can use JWKS to validate the token instead of talking to the IdP.
Are you suggesting that, that is somehow insecure?
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.
> At the request of the members, the Security Services (SAML) TC has closed.
0: https://news.ycombinator.com/item?id=41056529
There are tons of orgs that have built SSO on SAML so it won't die for a long time, but it's a frozen standard. From my understanding, it's frozen because no one wanted to put in the time to improve it.
OIDC doesn't scale, and OIDC Federation is still in draft. SAML Federation is mature with wide support and good discovery UX thanks to SeamlessAccess.
SAML has a variety of standard attribute bundles, entity categories, frameworks, and profiles covering important integrations, e.g., identity assurance. These are slowly being defined in (or ported to) OIDC.
I like OIDC and think highly of the people working on it, but it's nowhere near as cut and dry as you suggest.
I think... it probably is as cut and dry as I'm suggesting.
The things you just listed sounds like unnecessary complexity that inevitably leads to the “too big standard” problem, where every vendor and id provider has their own half assed, incomplete and incompatible implementation of the standard, or worse - with security bugs. Something quite often seen with SAML.
That’s not to say that oidc or oauth doesn’t have alignment issues. See https://news.ycombinator.com/item?id=35713518 “We implemented OAuth for the 50 most popular APIs. TL;DR: It is still a mess”
Factually incorrect
Frankly I’d suggest the same thing about Okta but as bad as they are whatever you do to avoid them would probably be worse in practice.