[bsid]

Also, IAM usually means SSO solutions for employees i.e. things like Okta/OneLogin..

CIAM usually means external facing authN/authZ.. (customer identity and access mgmt)

There's so many terms in this space that are already confusing.

[verdverm]

SSO is really just the Identity part, and one way to prove identity, more conveniently across many systems.

SSO misses the Access (permissions) part, which requires policies constraining the acting identity, the target, and the action to be performed

[deathanatos]

No, they're still intertwined, unfortunately.

For example, Okta has a notion of whether a user is "authorized" to use the app, so you can end up being directed to Okta, prompted to log in, and then shown an authorization error. Users will often phrase this as some odd form of "not permitted to log into the app".

Further, Okta admins control the claims the user presents to the app, and those claims can often have authz implications. A "role" or "group" claim is the most obvious one.

I've spent endless time going in circles with Okta administrators who can't clearly delineate these two, or who don't understand what an "app" (Okta's term for a relying party) is, etc.

[verdverm]

You may be conflating Okta a bit here. SSO is one feature of Okta, which stands for Single Sign On. SSO is typically used to enable users to sign into their core work account and then that login is used for all applications where SSO is enabled for the organization. If Okta is conflating things on their end, that does not make SSO mean more than it should, just that some group of humans is misappropriating terms.

[deathanatos]

You and I can separate out SSO-the-feature from authz features, but it's all one product offering from Okta. A normal end-user is not making those distinctions.

> If Okta is conflating things on their end

Okta need not conflate anything; a layperson is going to see "Okta is our SSO system" → "Okta provides these things", and there you are.

But groups muddy the water even further. Your SSO system is making authz decisions. If someone (reasonably, and correctly) asks, "can I have permission to use $app?", … and that app assignment is then made in Okta, there you are.

Okta is far from the only such SSO to have such features, but it's also ridiculously widely used.

(I don't know that I like that Okta hands app assignment to administrators, and not users, but such is the case. But things like group or role claims — essentially whatever passes for a modern day directory — that's authz, more or less, since the groups directly dictate.)