I love to see OIDC gaining traction, though I will say that for setting up any sort of custom workforce federation, the administrative experience for OIDC applications often feels like an afterthought. I haven’t looked at all implementations, but I have recent experience federating SAML and OIDC applications in Okta, Google Workspace, and Entra ID.
Amazon also has pretty explicit preference for SAML if you want to fine-grain certain things, it's much easier if you need to connect AWS to external SSO without going through AWS SSO (which, last time I checked, had to be "global" thing for whole fleet of accounts, which makes problems when you need some sub-accounts to have different SSOs)
They say this in how you simply are limited in what you can pass and control when using OIDC Vs SAML.
SSO -> token that works only for specific role, where the specific user is supposed to be able to take many roles, is very hard to do with OIDC unless you can mangle OIDC tokens properly, whereas it's way simpler to do with SAML
I'd love to read about that more if you can share links explaining those details.
Whatever you've described sounds more like internal problems / challenges of their own implementations than anything else... especially the OpenID Connect as a delegated authentication protocol itself.
It's been over 2 years since I dealt with it, but in essence the details boiled down to much bigger size limits for SAML assertions vs. how big a JWT token could be passed to AWS STS for AssumeRole call. 100000 characters of base64 vs few kilobytes of JWT, an error we hit very very early.
Also, for practical purposes, you can parse available roles out of SAML2 response from IdP, presenting a menu to the user asking them to select the right role.
To deal with OIDC having way smaller space for "assertions", I ended up adding extra parameters to OIDC login request, and modified our IdP (keycloak) to parse it and filter user's groups (set from AD) to only include the group passed in parameter. This way we could always "fit" inside OIDC token limits in STS.
This was in regulated environment where users had to be given very fine grained access, and simultaneously could have many, many, many roles available - and had to be able to switch between them at runtime. I think we blew the STS the moment we fed the IdP with real group membership dataset instead of the less than 10 groups we had used in tests. Don't recall if it also didn't trigger some really hilarious errors that I recall seeing, like Sagemaker exploding with EC2 ENI attachment errors, but that one could have been triggered by something else.
If we look a bit closer, we notice that the first four use OpenID Connect under the hood. These names are fancy names for OpenID Connect with a little bit of something extra on top from Apple, Google, and so forth.
AWS SSO, ASS Cognito, and SSO (SAML/OIDC) integration in AWS IAM/STS are all three different things, with separate behaviours, problems, typical Amazon undocumented pitfalls, etc.
