Hacker News Reader

Comment by verdverm | Hacker News Reader

"Identity" and "Access" Management (IAM) is pretty standard terminology.

I personally like saying authnz (authentication and authorization mashed together)

"Login" doesn't really cover token or key based authentication, i.e. service accounts don't "log in" but do require authentication and authorization

View on HN

"Identity" and "Access" are really good names.

I could easily adopt those if I find myself naming middleware again.

I have found that "access" gets confusing from an audit perspective, and have had to explain to many people that the list of people who have accessed something is a subset of those who have access to something.

I like "permission" for the concept of "allowed by the system to do".

I like "activity" or "actions" for things users have done.

The modern parlance doesn't accommodate but the original "log in" and "log out" describes any time a use enters or leaves and is noted in the log. This goes back to shipping whereby persons entry or exit would be noted in a log. Imho that older definition would cover nearly every type of authentication that results in someone connecting to a service.

This doesn't seem to cover API keys or bots, which have authentication mechanisms, but who's typical workflows lack the "enters" or "leaves" concepts you describe.

For example, I can log into OpenAI, generate an API key, log out, and then use that key to access their systems across a network

Sadly most of modern communication infrastructure is built on the stateless substrate of HTTP, where every interaction starts from a fresh slate. And zero trust networking suggests we should not rely on border checks to let people 'in' and 'out', but rather check access control at every interaction.

Really, modern practice has moved past 'log in', sorry.

Yes. But logging in still happens - you just get a token in response and use it for subsequent communication within some time period. It’s still a bad term for an identity / authentication system because logging in is just one small part of it.

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.

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

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.

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.

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

Identity and access seem much clearer to me. Not every identity determination is via log in, not every access check is purely based on permission. I will try and use identity/access/IAM instead of authn/authz/auth.

Yes, this. Access control is bigger than just permissions. And identity is still relevant even for anonymous users.

> I personally like saying authnz (authentication and authorization mashed together)

a12n and a11n, if you will.

which ideally are a11y (accessibility)

The other term you might here is AAA: Authentication, Authorisation, and Accounting

by Accounting, do you mean Audit Logs?

That is a form of Accounting, yes. There are others though, like metrics, and Accounting is meant to mean all of the recording/telemetry.

I can see this thread rabbit-holing into logmon terminology :]

This also goes back to dial-up days when your third party modem bank provider would also send accounting packets as well as authentication and authorization.

Came here to say this. Is how i learned it decades ago and the importance of each with Radius.

> "Login" doesn't really cover token or key based authentication, i.e. service accounts don't "log in" but do require authentication and authorization

To build on top of this point, authentication also includes claims that are not tied to an authorization process, such as user agents or custom request headers, and authentication is often used not to reject access but to output subsets of data (I..e, hide fields from a response, send a specific response doc, etc)

It's as if the whole industry uses the keyword "auth" for good reasons.

Reply on news.ycombinator.com