You may be correct there. I seem to remember being able to handle that over SAML but could be an extension…
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 allows you to send additional attributes with the identity payload, like group memberships. This is not inherently authorisation, but can be used to automatically map users to teams/groups/roles in your application.
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
The authorization model is bespoke to your ecosystem. Whether you do that with claims, scopes or assertions is irrelevant. None of these are hacks, but they can’t be simply standardized either. Provisioning/Deprovisioning is a separate concern; SCIM is one way (but just in time provisioning can also be achieved with both solutions).
There’s no reason to choose SAML other than for legacy integration.
The usual tagline is that "OAuth is authorization, not authentication". OIDC is an authentication layer built on top of OAuth. This means that OIDC can be used for both authentication and authorization to a third party API - most OIDC implementations allow the client to request an ID token (for authentication) and a traditional OAuth Access token (for authorization) in a single transaction. Clients can opt out of the authorization process by requesting only `response_type=id_token` and eschewing an authorization code entirely but that is not so common.
SAML does not grant any authorization to an upstream API.