Removing the user from your application immediately and not when their session eventually expires.
Doing those things in batch.
Querying that data at will to produce reports.
Updating a users group membership when needed and immediately and not when you decide to do so.
And then you only need an opaque userid from me and not a fat OIDC token that knows everything about my internal structure.
This is orthogonal to OIDC, unless you're using it to transfer groups in the token (don't).
> Querying that data at will to produce reports.
How the heck is this OIDC/SAML functionality?
> Removing the user from your application immediately and not when their session eventually expires.
OIDC allows the same workflow. The app just needs to be able to validate the session from the `sid` claim.
> And then you only need an opaque userid from me and not a fat OIDC token that knows everything about my internal structure.
OIDC tokens are opaque.
Regardless OIDC is authentication not authorisation. OIDC asserts who you are not what you are allowed to do, where SAML asserts what as well as who.
I mean you could hack assertions into scopes somehow and return it in the OIDC token but that’s not really standardised and everyone will just decide what they are going to add whenever they want which is at best no better than SAML using JS instead of XML.
SAML is a very complicated standard, and very painful to implement. OIDC is much simpler, but lacks some of the capabilities.
Both can automatically create users on login, that is application implementation detail. Both also need SCIM or something similar to offboard users
This is how OIDC does it, too; group membership is a claim.
There’s no reason to choose SAML other than for legacy integration.
Just also don’t automatically assume one solves all the problems of the other, there is still some significant difference between them that makes SAML something the businesses will ask for.
SAML does not grant any authorization to an upstream API.