4 ms·
Creating the user in your application before first logon. Removing the user from your application immediately and not when their session eventually expires. D
by jpc0 1y ago
Creating the user in your application before first logon.
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.
- maxwellg 1y agoThese are all features of SCIM, not of SAML. SAML only communicates user metadata on login. SCIM can be used with both SAML and OIDC.
- jpc0 1y agoYou 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.
- T-Winsnes 1y agoSAML 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
- deathanatos 1y ago> SAML allows you to send additional attributes with the identity payload, like group memberships. This is how OIDC does it, too; group membership is a claim.
- lll-o-lll 1y agoThe 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.
- jpc0 1y agoI don’t disagree, I’m all for OIDC + SCIM if it isn’t clear from my comments. 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.
- maxwellg 1y agoThe 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.
- cyberax 1y ago> Removing the user from your application immediately and not when their session eventually expires. 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.