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.
CIAM usually means external facing authN/authZ.. (customer identity and access mgmt)
There's so many terms in this space that are already confusing.
SSO misses the Access (permissions) part, which requires policies constraining the acting identity, the target, and the action to be performed
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.
> 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.)