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¹. Which do we mean for an "auth system"? It's never perfectly clear and, unfortunately, we often mean both.

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!

The current terms fall short

Calling things just "auth" is common. It's used in library names (django-allauth is for authentication, and go-auth is also authentication), package names (django.contrib.auth, which does both authentication and authorization), and even company names.

Since "auth" can mean two things, this naming leads to ambiguities. When you see a new auth library or product, you don't know right away what it's able to handle. And when you talk about it, it's also not clear what you're referring to.

The canonical solution is to call these "authn" and "authz", the n and z evoking the longer words. Thes are just not satisfactory, though. They're clunky and hard to understand: they're not universal enough to be able to skip explanation; they're easy to mishear and are close together; and what verb forms would we even use?

It's not just about bad communication, though. This terminology implies that the two concepts, authentication and authorization, are more closely related than they are. It encourages bad abstractions to combine them, because we have one word, so we feel like they should belong together. But they are two pretty fundamentally distinct problems: checking who you are², and specifying access rights.

There are some links between auth and auth³, because what you can do is tied to who you are. But they're also very different, and deserve to be treated that way. At the very least, recognizing that they're different leads to recognition that solving one does not solve the other.

Instead, use "permissions" and "login"

We should always use the most clear terms we have. Sometimes there's not a great option, but here, we have wonderfully clear terms. Those are "login" for authentication and "permissions" for authorization. Both are terms that will make sense with little explanation (in contrast to "authn" and "authz", which are confusing on first encounter) since almost everyone has logged into a system and has run into permissions issues.

There are two ways to use "login" here: the noun and the verb form. The noun form is "login", which refers to the information you enter to gain access to the system. And the verb form is "log in", which refers to the action of entering your login to use the system.

"Permissions" is just the noun form. To use a verb, you would use "check permissions." While this is long, it's also just... fine? It hasn't been an issue in my experience.

Both of these are abundantly clear even to our peers in disciplines outside software engineering. This to me makes it worth using them from a clarity perspective alone. But then we have the big benefit to abstractions, as well.

When we call both by the same word, there's often an urge to combine them into a single module just by dint of the terminology. This isn't necessarily wrong—there is certainly some merit to put them together, since permissions typically require a login. But it's not necessary, either, and our designs will be stronger if we don't make that assumption and instead make a reasoned choice.