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.

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.

They are suggesting that it’s easy to make mistakes when writing the JWT auth code as opposed to just talking to the IdP using TLs

If I’d been in a position to, I would have. Except for Sam Quigley who was the fucking best.

I was also the SAML person at one point in my career and I 100% agree. I used to laugh at all the HN criticisms of JWT because of how much of a nightmare SAML is.

Cthulhu does not appreciate being associated with this.

Do you renew the certificates used to distribute the public keys in SAML metadata, and if so why do you do it? I have had a hard time convincing people it is useless to renew those certs and have yet to find an implementation that care about those certificates.

Yes, JWTs are so simple compared to what came before that it's hard to argue with them. Just make sure your verification doesn't allow none or old ciphers and you're basically fine.

I'd argue you're half right.

Yes, it is a good recommendation if the customers have an IT Department.

But I'd argue you're missing the other half.

It's an even better recommendation if the customer is using M365, Google Workspaces, or Apple Business Manager, without an IT Department, since they don't need an IT Department at all to get effectively the same benefit as SSO.

After your initial setup to accept OIDC as the SaaS or PaaS, neither you nor the customer have to do an "integration" to support additional customers of Microsoft, Google, or any other OIDC provider you add. You could let your customer validate an email domain to ensure their sign-ins are theirs, but other than that, once you support OIDC with their provider, nobody has to do anything.

Something on the order of 80% of SMB in the U.S. are on O365/M365 by some measures, and judging from startups here, every tech startup thinks everyone's on Google Workspaces like they are, so that's the other 80%. :-) Toss in socials if you are B2C instead of B2B, and of course Apple IDs if you are targeting users by "wallet share".

You get the key benefit of SSO while your clients do not need to integrate one by one. And...

> Use an open source identity provider or pay someone to do it for you.

Or, don't do that effort at all, use what's baked in and just take the win.

XML is marginally more complicated than JSON: attributes and namespaces.

Apples to apples, is it's not much different. XSD is just as complex as JSONSchema.

Verbose? Sure.

But people love XML so much, they invented JS-and-XML (JSX). :shrug:

We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all.

At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.

Microsoft Entra having first class support for OIDC really helps; I remember seeing a decision diagram in their documentation recommending using OIDC for new projects, it can help negotiating. Google Workspace also works just fine with OIDC, and so does Okta.

I've been told that the only source of problems is going to be companies using Shibboleth, even though there seems to be an OIDC plugin.

Yeah, SAML will probably fade away (slowly). And sometimes, you might be able to convince the customer just to use OIDC.

But human behavior change is hard and expensive. For the most part, it's just easier to give the customer what they're asking for / what they expect, even when you know they're wrong.

When you're trying to push an enterprise deal over the finish line, this is often just not a good enough reason to introduce friction with your buying committee.

And if you have to support SAML for one stubborn customer eventually, you might as well support SAML for all customers that really want it.

What I'm saying is you can implement the functionality of the parameter -- i.e., arbitrary data that survives a round-trip through a SAML login -- without literally using RelayState.

For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers.

It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.

Oh don't get me wrong at all -- deprovisioning is huge indeed!

I'm not going to misleadingly edit my initial comment, and your comment is fair. I said "just" when I should have said "precisely". As in, I was already talking about how SAML interacts with "Bob from Sales got fired, probably should kick him out of the CRM". SAML gives you "Bob can't log into the CRM ever again", SCIM gives you "... and his CRM user and sessions are immediately revoked".

To be clear, SSOReady also has a "SCIM made easy" API, we definitely know about and care about helping people implement SCIM: https://ssoready.com/docs/scim/scim-quickstart