Instead of “auth”, we should say “permissions” and “login”

"Authorize" and "Authenticate" are excellent words. They go back to medieval times and haven't changed meaning too much.

Everybody knows what an "authority" is. It means they have power or capability.

Everybody knows what authentic means. Something that is proven to be genuine.

The difference between the two concepts, as they are used in crypto systems are specific, important to get right, and also inherently intertwined, confusing, and subtle. I'm skeptical that changing the words would help.

It's one of the many reasons we have the saying, "Don't roll your own crypto."

Trust and verification are just hard problems.

"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

I don't really get the point of this post. Yes naming things is hard, but the fact that these two words are similar is actually a good thing, despite laypersons getting them confused, because they are both functionally and implementation-wise closely related. The confusion is not going to be solved with trying to relabel the concepts. The author never actually illustrates the harm caused by this confusion either. My guess is they ran into something like installing a package that didn't cover their desired needs, attributed this to the "auth" name and instead of moving on decided to write about it.

> "The canonical solution is to call these "authn" and "authz", the n and z evoking the longer words."

or we could just use the longer words?

I've never been in a situation where this "confusion" happens (nor in english or spanish, where we use autenticación and autorización), authentication and authorization are standard terminology in all IT and Infosec.

I know acronyms and stuff but if it creates confusion just use the damn complete word, I don't get why create a problem.

Or use the industry standard AuthN, AuthZ nomenclature?

I like it. The distinction between Authn and Authz isn’t nearly as obviously as login and permission. Sometimes I feel like we enjoy fancy terms more than we enjoy unambiguous terms.

The problem goes way beyond any singular ecosystem and extends to the most basic standards as well.

For me one of the most confusing things about this topic is the use of "Unauthorized" in 402 [1], when the dictionary definition is about not having permission and authority to do an action [2].

So in my projects I usually use:

- 402 - Unidentified (identification) ou Unauthenticated (Authentic identity)

- 403 - Forbidden (permission)

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401

[2] https://www.merriam-webster.com/dictionary/unauthorized

I have worked with auth (:P) systems (IAM) a lot and I have never seen the problem with "auth" meaning both authorization and authentication. When more specificity is needed, just use the right phrase.

Using "login" and "permissions" are worse IMO, because they don't catch the entire meaning and complexity of these systems. Authentication means way more than login, and permissions mean very specific things for a small portion of an authorization system.

Most places I've worked have standardized on AuthN and AuthZ as shortcuts for Authentication (login) and Authorization (permissions).

Do other folks have different experiences?

I prefer AuthN and AuthZ.

I don't think sharing a prefix/root implies that they're the same thing.

Also, I don't think the suggested "permissions" and "login" terminology would work for all AuthN/Z schemes. For example, when exactly do you "login" when calling an API with a bearer token? Doesn't work for me.

Maybe instead of overloading the shorthand with two definitions, it's best to just use the actual words.

Isn't there are rather obvious solution to this "problem"?

When we need to be clear, let's call authentication and authorization... authentication and authorization.

This sucks... authorization and permissions are not the same thing.

Permissions are rights or privileges, which exist independently of their assignment to particular users.

Authorization, on the other hand, can have two meanings - both of which relate to _assignment_ of permissions to users (preferably via groups or roles):

1. The process of assigning permissions to users, as in "you need to be authorized to do that".

2. The process of confirming whether a user has the necessary permissions to perform some action.

The second meaning can also be referred to as access control (or more precisely, runtime access control). It's what applications typically do after authenticating users. Hence, if you want an alternative to "authorization" in the runtime verification sense, the term "access control" might be appropriate.

On the other hand authN and authZ are perfectly adequate and well-understood.

Since the term "authorization" always relates to a (direct or indirect) binding between permissions and users, it makes no sense to use the term "permissions" as a substitute for "authorization".

NB Security practitioners typically never say “auth” due to the ambiguity; we typically say “authN” or “authZ” for clarity, or use the actual terms authentication and authorization.

“authn” and “authz” are sufficient to use between technical people.

But using “login” and “permissions” for explaining concepts to general populace is perfectly fine as well.

Instead of plural accesses we should say entitlements

Permissions to me is about setting a policy and authorization is applying that policy.

I have never wanted to use them interchangeably.

This terminology implies that the two concepts, authentication and authorization, are more closely related than they are.

But they are closely related. You can't really have authorization without some form of authentication. Both are tied to some kind of identity. And in some cases, such as SSO, authentication involves authorization from another system.

Also, login is not a good replacement for authentication, because there are forms of authentication that don't involve logging in at all. And often the act of logging in just exchanges one set of authentication credentials (username and password or equivalent) for another, shorter lived, set (token, cookie, etc.)

Finally, one nice property of using authz and authn is that you can use "auth" to mean "authentication and authorization", since the two often go together.

Auth is what you went for when "cloud" or any number of more widely used ambiguous terms are out there? That said I think dialing back the use of technical terms watered down by the marketing team would be fantastic.

I think this only works in limited versions of these auth systems. If that’s what you want, great. Some packages for various languages already exist for this purpose. They’re incomplete auth systems, though.

There are more modes of authentication than logging a user into a system or referencing their proof of authentication after login. It’s certainly the most common use case, but authentication can occur using other forms of proof that you’re willing to trust.

For example, someone in your system invites people to do something via email. Once these people authenticate by entering a code sent to their email address, you trust that they can access a file based on a cookie you’ve set. However, they are not logged in because they don’t have an account. You would not do this with a login system. You’d do it with an authentication system.

Yes

Agree with the article. The worst offender is probably Oauth providing endless confusion to developers and end users

I think it should be “authentication” and “permissions.”

There’s pretty much no word in the English language to describe login/account creation/etc than “authentication.” The word “login” is a poor substitute. There are no good synonyms for “authentication” that encompass all its applications in computer systems.

Meanwhile, there are already lots of synonyms used for “permissions.” Given the abundance of these, and the lack of synonyms for “authentication,” choosing “authorization” to describe permissions is, frankly, an asinine decision. It adds unnecessary cognitive overhead for everyone.

(That’s not to say there’s no place for, say, Unauthorized responses, etc. Just that we should be calling the topic “permissions” or really anything other than “authorization.”)

So we are back to the most difficult things in programming: naming things.

Honestly, Im tired of people telling me how to talk. What if instead of policing language we educate people on the differences between authentication and authorization and best practices for implementation? I think you’re onto the problem, but artificial language enforcement isn’t going to fix it.

I do not like it. AAAA is a good abbreviation for the necessary principles authentication, authorization, access and audit.

LPAA... Is just not right.

No.

Most computer systems we interact with have an auth system of some kind. The problem is, that sentence is at best unclear and at worst nonsense. "Auth" can mean at least two things: authentication or authorization

Yes, that was the point of using auth.

"Permissions" seem too specific a term to use as a general term. It's something I'd use to describe the specific rights a role may have in role-based access control, and not authorization as a whole. I'll stick to authn/authz for abbreviations, auth for both or if it's not specific, and if it's for documentation or cross-department communication I'll just write the whole word.

Ah yes, the good old “the jargon for X is confusing, let’s add more jargon”.

I get what you're doing, but the problem is that "login" and "permissions" are ambiguous in the context of Identity Management. For example, "Delete-User" is a permission that defines some 'permitted action', but it does not imply "Administrator" role or a set of policies that should be governing access to some resources. So by trying to fix one semantic issue, you're introducing a bunch of other ones.

We carry a physical analog of this in real life: work badge. My policy-enforced visible picture identifies who I am and that I match that photo and also gatekeeps me into and out of places I'm allowed to enter.

terminology implies that the two concepts, authentication and authorization, are more closely related than they are ... There are some links ... because what you can do is tied to who you are. But they're also very different

AuthZ being entirely dependent on AuthN is not "some links". That's an unbreakable dependency.

I can agree that these two words being a single letter apart are easy to conflate though. But as they are related, we're more likely to increase training/education around the concept rather than rename them.

“Login” implies a state change, which “authentication” doesn’t.

“Authorization” can refer to a process, which “permissions” doesn’t.

If you think ‘auth’ is confusing in an access management context, wait til you implement a payment system and discover that credit cards have an ‘auth’ process that has nothing to do with your user identity or user permission checks. A credit card auth is not ‘authenticating’ the card holder, or determining if they are ‘authorized’ to charge to a particular card. It is instead the process of being given authorization to capture funds from a payment instrument.

Totally agree with this article and I'll try to use these words.

Sometimes someone just points out the obvious, and it's obviously a good solution. I'm happy to never use authn or authz again, good riddance.

This is a widespread problem, and it's well known. One common solution, using the terms "authn" and "authz", doesn't solve the problem. And this isn't just confusing, it leads to bad abstractions and general failures!

Well, in written language, authn and authz aren't mistakeable. In spoken language, I never heard anyone say authn or authz, but their fully developed versions.

And about bad abstractions, I believe that has less to do with bad naming and more to do with the fact that authenticating and permissioning is hard to express, develop and to scale in a secure and reliable way.

I think a better use of time is to worry less about how to rename these moving parts and spend more energy studying the pitfalls like the confused deputy problem and how it could apply to your specific domain or use case.

Between dev and administration/ops work, I spent a couple of decades in the deep end of the tech pool. As we know, it's packed with layers of interconnected archaic, arbitrary and confusing terminology. I understand the resistance to renaming things – the cognitive overhead of learning new terms is real. However, when you remove decades-irrelevant technical limitations and contrived entomological justification, the reason for sticking to old, confusing names often boils down to "because I already know it." Many feel learning it all has earned them this machismo-driven badge-of-nerd-honor, and people advocating for more straightforward terminology are often viewed as weak, lazy, or incompetent. That's convenient for us, but hindering future generations and confusing non-technical users has a cost. For a field so focused on progress, this resistance to improving terminology is strange. While I don't advocate for constant change, or change for its own sake, we should challenge "because, that's the way it's always been" as a justification for not making things better.

I've always heard "auth" to mean authentication and "perms" to mean authorization.

We do in infra/infosec/sysadmin. Sounds like a dev that just isn't familiar with the territory. That's why we have different departments.

I lead on the team responsible for auth on our product, and we just go with authN and authZ when we don’t mean both.

'"Auth" can mean at least two things: authentication or authorization' - the two words you should be using.

This article took some time to think through, reason about and write, likely with years of experience as a prerequisite.

Some articles/proposals like this are beyond what current AI could offer, but it’s interesting to see which ones.

Asking Gpt4o, it gives:

Authentication: Verify Authenticate Login

Authorization: Authorize Permission Access

So in this case, it was able to offer the same suggestions as the author as well as some of those from the comments below.

And script, instead of "app".

On a mildly related note, I have been doing NUMEROUS things lately in order to speed up our PHP-based social network platform, so it would load super-fast and handle a lot of traffic on one machine. They include:

1. Inlining all CSS and HTML if there is no session cookie. (But not JS because people just need to see the page as soon as possible, and JS doesn’t have to get in the way)

2. Having a service worker store all the inlined files, so next time they are loaded from the cache. But change back the @import() statements in CSS (because the CSS file may be at a different path and sadly the stylesheets don’t have a way to set a <base>)

3. Using Q.getter() for caching and throttling, Q.batcher() for batching requests. All people have to do is request individual objects and the system will batch them (in groups of 50) so the PHP can do queries about many rows.

4. A PHP script to go through with multicurl and render various pages to static HTML (for top-level) and JSON (for dynamic requests). There are two versions of the HTML: a) when there is no session cookie and b) when there is. Both versions of the HTML insert a <base> tag, because they may be placed in a different path so as not to pollute the directory.

5) But when the session cookie is authenticated, the value begins with “Q_sessionId_authenticated_” as opposed to just “Q_sessionId” so the server (eg NGINX) knows to hit the actual PHP and not just serve the static files.

6. Have PHP check whether a path was rendered to static, check the above rules and 302 redirect, for people who use commodity hosting and can’t change the webserver configs. It’s a but slower but at least the PHP exits early.

7. Speaking of exiting early, every session ID is generated by the PHP script and signed with an HMAC (secrets are stored in local/app.json which is listed under .gitignore and .hgignore so it’s never accidentally checked into repos). That way when a request comes in, the code quickly checks the sessionId and rejects if it’s bogus. This can protect against DDOS, eg with cloudflare workers at the edge.

8. Speaking of CDNs. We have a system to map any subpath to any URL, including external CDN URLs so you can host various CSS/JS/image packages elsewhere, and not need to have your server be an origin server

9. We also have bundle.php to bundle everything for app stores. Think of it as a longer-duration CDN cache. We then save the cache timestamp during build time and send it a Q.ct cookie during requests (eg from a Cordova app). If the css/js/png/other file on the server is newer, it is referenced from a URL with a newer ?Q.cb={{timestamp}} for cache busting.

10. We have an update.php script to generate updates / releases of the app, which goes through each changed static file in the public directory (including traversing symlinks) and records its timestamp. We also have an option to record its content hash (for subresource integrity checks).

11. We have a way to upload / download PHP code from the Internet without having to log in with SSH etc. This allows updating the software packages even on commodity hosting. The packages contain resources that can override previous resources. But they are only loaded after checking the cryptographic signatures — there have to be at least two, taken from a list of audit organizations that the sysadmin trusts. We ship a list that we trust but the sysadmins can change them (eg if they suspect the auditing companies are under our control).

This post has become too long. You can see much more info on our forums if you’re interested

https://community.qbix.com/t/qbix-websites-loading-quickly/2...

90% of development and IT is knowing acronyms and abbreviations. The other half is skills.