Hacker News Reader

Comment by maxwellg | Hacker News Reader

These are all features of SCIM, not of SAML. SAML only communicates user metadata on login. SCIM can be used with both SAML and OIDC.

View on HN

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.

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.

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

> 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.

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.

I 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.

Reply on news.ycombinator.com