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.

If something is fast, it moves quickly or not at all. Cocktails can be garnished, but so can wages. Sales or trade of a product could be sanctioned by one country, but sanctioned by another.

I generally think it is a good thing to communicate clearly. Sometimes that means using words differently to explain something. Other times, that means using words the same way as others. I think this is a case of the latter.

Also, I think the idea of "native speaker" is a bit of a red flag. There are plenty of people that speak English from birth but are utterly unintelligible, and there are plenty of people that speak English as a second language who speak more clearly than those.

It is, unfortunately, possible for more than one thing to be bad at a time.

Garnishment of wages is garnisheeing, though here I'll agree "garnishing" seems to be acceptable too.

Edited to add: Sticking with the context of food, "fasting from food" contradicts someone being a "fast eater."

It’s already universally used in IAM, where the other half of the puzzle is also clear and free from ambiguity: “Access”.

KYC (know your customer) are about removing the ambiguity between you user and their identity....

Identity is who you really are. Be that you as an individual or as a corporation.... In the case of your bank they have a copy of your ID, your SSN, for them identity is what established the account and auth lets you work with it.... AWS might know some members of your company (either by corporate or individual card) but might not know your identity (as an individual) and yet you can still authenticate, because you have been authorized by an identified customer. I can transact with crypto as an authenticated user and NOT be identified.

Iirc, Java or J2EE used “Principal”, which I found super confusing

To “log in” is to convert the username/password pair (or API key, or whatever) into a smaller token with an expiration. Doesn’t matter of it’s put in a cookie in my browser, held in memory by some other API client, etc.

Aside: Why bother even doing that? Because every time you transmit the credential, there’s the possibility of leaking. We would rather leak the token that has an expiration.

“Permission” and “persistence” have the same prefix but entirely different semantics. They also occur more commonly in everyday life.

AuthN and AuthZ are similar in in spelling, appear in similar contexts, and are less colloquial, making the distinction a lot less clear.

There’s a reason many junior devs use them interchangeably without knowing better.

I think the reason junior devs get them confused is that many junior devs are never taught anything about either in school. But then you just tell the junior dev that they mean different things and in my experience they only need to be told that once.

Ultimately I think it’s fine to use vocabulary.

Hence the confusion and ambiguous shorthand "auth". You auth and gets everything. You fail to auth and you don't have access. That covers ~80% of any authentication-authorization-accounting systems use cases, and that allows people to be care-free about differences.

As a dev you're either building or hooking up to either or both of them. And you know what each requires you to build / hook up to.

As a user, you just care "I put my login/password/api key here, and I get the capability to do several things in that webpage/service/etc". Both auth and the other auth are handed for you.

And if the other dev made an error and confused authorization and authentication you have a problem.

Stupider mistakes have been made and it is a sign of overconfidence if you think you are immune to them.

This is a problem with only one solution: continue to improve one's skill with the language. You can't solve this by choosing different terms, because then something else will be the "this is confusing to non-native speakers" hangup. You can whack those moles until the day you die and you'll never get them all.

__________

[1] Derived from the signing of a ship's logbook³ when coming aboard.

[2] A few decades ago.

[3] The logbook originally⁴ recorded navigational data and is named for instruments measuring speed through water⁵, of which the simplest is literally throwing roped wooden logs off the stern and counting the knots on the line paying out per interval⁶.

[4] Doubtless some bright-eyed young hornblower with a glittering future career as an admiralty archivist realised that log-structured records could be generalised usefully to all timestamped event and measurement capture, which is why your syslog is full of crap.

[5] Consequently any vessel, maritime or otherwise, measures its speed through the medium in knots. The Enterprise NCC-1701-D, for example, tops out ca.146 megaknots under impulse engine.

[6] It follows by transitive etymology that you may use the term "knots" to edify and delight your colleagues when referring to the rate of creation of user sessions.

Related words for related concepts is very normal, and if you are a professional in this space it's the least we can do to recognize the difference. We aren't astronauts, we have the time to figure it out.

Language learners already learned a second language, they have the skills to figure this out. At least it's not a homonym.

From an end user perspective, auth is the problem. Users can’t determine what is login vs permission. If non native speakers can’t handle the distinction, it’s a valuable lesson to learn.

Why would we choose "login" - which is more of a special case than the norm to describe something we already have a precise term for?

I'm a native speaker and I need to pause for a few hundred milliseconds just to be sure I'm using the right one in a sentence.

What does "unauthenticated" even mean here? You aren't logged in, not logged in isn't a state of "unauthenticated", you haven't given any credentials meaning currently you don't have any authority, so unauthorized makes sense. You can have several sets of credentials and switch between them, not giving them any isn't being in an unauthenticated state its a different thing, and using "unauthorized" in that case makes sense.

Once you log in, you are granted authorization for certain tasks. This could be rights to an individual record or column, or it could be administrative privileges within an app. It's not involved in determining who you say you are; it authorizes you to access things based on who you are (from the act of authenticating).

That's the way I understand those two terms and their practical applications.

We give oranges and apples those distinct sounds, while giving blueberries and strawberries very similar names. It's just makes no sense that we should change the latter two so no one mixes them up trying to sprinkle some on yogurt.

Same problem when someone wants to substitute "login" for "authenticate" - not synonyms.

Better title would be 'instead of authz & authn ...' to make that clear, because it does just sound like they haven't heard of the concept at first.

I have always heard and used authz and authn (pronounced auth-z and auth-n). Bare "auth" typically was used to mean both, but IAM was more clear for that in specific contexts. E.G. you might say someone "authed" to indicate both authentication and authorization, and you might have an IAM team that handles both authentication and authorization.

FWIW, I lead an IAM team.

Real travesty came from OAuth. A system designed to handle authorisation was named after the term for authentication.

In security, anything that is less prone to error is good, so words that are hard to confuse or misspell are good.

The concepts are different so it's not like a dial you are turning to make a measurement, the terms are for different domains

> Why would you type the wrong letter when you mean the other one?

Really? Ignorance, laziness, rushing, fatigue, simple mistakes, etc.

What I think is worse is more letters doesn't save you. I've had some conversations where it has gone like 2–3 round trips before the other end realizes that "not" means not, and they mean … the other way.

Replacing terms - that have been around so long that many systems' behaviors map to them closely - with new terms that don't quite overlap seems wildly more likely to create ambiguity and confusion.

login is at best defined as authorization + authentication

but things which are in general referred to as login but only provide authorization are not that rare (e.g. you pass a token to a client)

and logins which to provide authentication but not authorization exist to (but are rare and you probably could always nitpick them out of existence)

Similar the term permission is hugely overloaded due to it's wide usage in more causal most times end user facing documentation. Most times permissions are used in a more generic context, like a user having the permission to do something vs. a request made by a user being authorized to do something.

I mean in the end there is no reason not to use login/permission for end-user facing documentations, causal conversations etc. This terms are "good enough" most times. But if you provide a login library or technical documentation for APIs with complex interactions between authentication and authorization then using login/permission just won't cut it.

Also for AuthN,AuthZ there is no point to use auto completion and there is very very little chance to mistype them as long as you don't confused them. Luckily this kind of mistakes do not fall under the patterns dyslexia causes (especially if you do the capitalization).

I'll try to articulate a bit though, but it probably needs expanding into more than a comment to have a chance at persuasion. When you start trying to derive logic chains that conclude in good, leading you to further conclude other things are bad, and base your decision making on what's good/bad in these chains, you've made a mistake. Engineering should be focused on trade-offs, not some binary and local good/bad. Engineering should be focused on measurements, not platonic qualities like "good". The world isn't so coarsely binary. So what if your results are better? Are they accomplishing something good down the line, like being better at [insert something you find morally objectionable]? And given we have limited resources, is the amount something is better worth expending the effort on it vs. something else, or even worth it relative to a measured good-enough steady state? Does the local change meaningfully impact the overall system at all? (You may be familiar with a semi-famous (around HN) article "The optimal amount of fraud is non-zero", if not, I recommend it.) Lastly, you need to actually look at what kind of errors there are, how they surface, when they surface (e.g. during software development, during design and prior to any code, during a test phase, or discovered by the end user), and their consequences for surfacing. You need to analyze whether something is actually less error prone or is just good at hiding its errors and continuing on. You need to look at whether the errors are loud or subtle.

All this high level chatter is of course further pointless in this specific concrete context. As someone already pointed out, it's exceedingly unlikely for a developer to confuse authN and authZ in practice for any significant duration. You can't just import and write code for authN when you meant authZ and expect things to "work" while perhaps errors accumulate (silently or not), because these terms express different concepts, different protocols, and different APIs. The code will simply not work, immediately. In a sense, this makes it quite error-prone if you typo what module you're importing to do your authN/authZ work. This isn't necessarily a bad thing because you'll see the error and fix it before it ever has a chance of impacting anything important. Would it have been better to not make the typo to begin with? Sure, but not meaningfully so. Focus on more important problems.

Meanwhile, to take a different concrete case, if you're writing crypto code and accidentally use ECB block cipher mode vs. CBC (a reasonable typo to be concerned about, even), everything will continue to appear to work. But you're already FUBAR. Of course, there are many subtle such errors in cryptography, and you can even choose the right cipher mode and still make huge mistakes that aren't immediately obvious, and not because of some trivial typo either. (Another semi-famous article you might want to check out, if you haven't, is "If You're Typing The Letters A-E-S Into Your Code, You're Doing It Wrong".) It's interesting to consider that the industry's broadest recommendation in the face of how error-prone implementing crypto code can be is to say "Don't" rather than to try and somehow make it less error-prone.

Hum... I imagine you mean people without any Latine inheritance in their culture. Those words are very good words on way more languages than English.

Those words are also shared with other domains, where they have compatible meanings, and that intersect the usage in computer systems. So you'd better fix them there too.

Besides "permission" is not a verb, and "login" is one between a lot of different ways to authenticate people. What do you intend to do with the correct meaning of those words once you overload them?

- Autorización : Authorization

- Autenticación : Authentication

- Autoridad : Authority

- Auténtico : Authentic

I would guess that in other romance languages, they are also similar to the English version.

"Log In", on the other hand, only makes sense in English. If you tell someone "Estoy registrando adentro" they will be dumbfounded.

A login is an active thing that you do, but systems can authenticate you with things like single sign ons, so that you don’t actually “login” to many of the systems you want to be authorised in.

Similarly permissions are the roles and claims your digital persona carries with it. These grant you permission to resources, but these can be trusted once your persona is authorised.

I remember when this saying referred to people rolling their own cryptography algorithms. When did it become about not doing your own auth? (I agree it's generally a bad idea, but curious about the scope expansion of the statement)

Some things in computer science are just plain "hard," and no amount of renaming or abstracting is going to solve it; you either need to take the time to understand it (i.e. learn authenticate = prove you who are, authorize = what are you allowed to do), or outsource the prob (e.g. "don't roll your own crypto").

Similar problems:

- Time. It's non-linear in calendar representations because of definition changes by humans. There are gaps in years trying to reconcile different calendars. There are leap seconds added based on scientific measurements, non-deterministic ways. Time zones enough confuse people. 99% of the time you can use something like "duration since 1970 UTC" (unix epoch) but you may eventually hit non-linearities if you try and say "once every 10 days" by doing 10 * secs / day.

- Names. Different all over the world. I won't even give examples because I'm still a bit confused, I recently learned that in parts of India first name and surname are reversed, so not even consistent in one country. Prob best to just put a "Name" field and a "Nickname / Display Name" field and let the user decide.

- Geodistance. The Earth is not a sphere, it's an "oblate ellipsoid" since the spinny makes the middle bulge. There are many ways to calculate distance between two coords and generally simple ones will work for majority of settlements. But if your customers are near the poles, or maybe include flight paths, etc the errors could be very significant. I've had this leak out in cases like Postgres where you can use the sphere approximation (much faster) or the proper calculationg (much slower) when running a query like "give me all points within a x mile radius".

Auth (hah!) is just another one intrinsically difficult concept that's not made more complex by language and can't be simplified away.

The only problem I have is that I can never remember which one maps to HTTP status codes 401 and 403. But that’s just a personal quirk.

Words mean specific things, let’s not dilute or overload the definitions of other words to avoid a confusion that may only exist in the mind of the individual writing the blog.

We already have so many overloaded terms in software engineering.

I was confused and it wasn't until years later that I realized that the similar/identical terms stunted my growth.

And yet a lot of the devs I work with (I'd even go a say most) can't really explain to you the difference between both concepts and use "auth" as a blanket keyword ; which that word allows since it has the same root.

I think that proposal isn't bad because it makes a distinction using simpler words. I'd also prefer for people to learn that simple difference, but that's what we get.

An analog to this is when I first stumbled upon words like a11y and i18n I had no idea what they meant. Now that I've actually had to deal with internationalization systems and accessibility systems I know very much what they mean, but similar to "auth" they're an umbrella invoking a large number of systems that can all function differently.

This sounds a lot like https://www.azquotes.com/quote/1026562

Sorry, but you're just wrong here. The words are speed bumps at best, and it would help a ton to use more instinctive words for them. Nobody needs to pause and think what login means, and that's not true for authentication.

this is specially complicated in fields with long histories. I've got an example that may only make sense in both english and spanish: fats, oils, gases/gasolines (grasas, aceites... gasolinas, petroleo)

other subtelties fresh on my mind today:

proposition vs axiom

argument vs parameter

(common) case law vs civil law

Also, I love how you say that everybody knows the meaning of those words yet you feel compelled to provide the meaning. Doesn't really make a good case in your favour.

I highly doubt laymen would understand the difference when using "authorize" and "authenticate" as opposed to "permission" and "login". I would bet you $100 in bitcoin that most people would understand the latter.

Our current implementations are like this. I'm not convinced this is inherent complexity, though.

It seems like almost all the complexity stems from people trying to create hooks to monetize all the pieces of the process.

Security and usability feel like a second and distant third in importance.

>> "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?

>> or could we just use longer words?

Agreed: relabeling, with longer words when necessary, can help.

My guess that's because palette, the real world object, is something close to a bar itself, so it would be a bit of tautology. From the dictionary:

Palette: a thin board or slab on which an artist lays and mixes colours.

Now we are in a weird situation where current flows from positive to negative, but electrons flow from negative to positive. It would be a lot more logical if the direction of the electrons was the direction of the current, but the name was arbitrarily decided before we knew what electrons were.

The conventional flow of current goes from positive terminal to negative. But electrons actually flow from negative terminal to positive.

However, in the typical case, what's moving is electrons, which means the "current" is flowing in the opposite direction of the movement of the electrons. This is stupid and everyone hates it.

In the coordinate system of an atom, the nucleus is at the origin, 0, while the electrons are a positive distance from that core. 0 is not negative, obviously, but it's non-positive.

When terminology is concordant in this way, the topic is easier for a student to grasp. When discordant, harder.

There's little chance for this wart to be remedied, invalidating every paper written up to that point is a bit of a non-starter. But I dislike it nonetheless.

Negating when you move electrons is just one more step, but so is negation within a complex expression in language or programming, and we do try to avoid piling that up.

  1. Sees 
  1a. "That's who I am, but to be sure..."
  2. "Ehh... the other one is... ..."
  3. " is what I'm allowed to do so..."
  4. "...yes, this one is who i am"

we could but don't expect anyone with dyslexia noticing that a text says authorization when they subconsciously expect authentication (and don't explicitly double check)

Through also if we use AuthN and AuthZ (with capitalization) it's quite clearly readable and hard to mistype and no longer the kind of words dyslexia makes it easy to misread (it never was in the category of things dyslexia makes easy to accidentally mix up when writing I think).

Using authorization and authentication also can have issues if you use a text editor with auto completion, for AuthN/AuthZ you simply could not use autocompletion.

> My guess is they ran into something like installing a package that didn't cover their desired needs,

or got into problems because they used the wrong term in technical documentation, maybe in context of a security review or a requirements document which has been legally binding singed of

> The confusion is not going to be solved with trying to relabel the concepts.

Especially given that login likely implies both AuthN and AuthZ so it's not even "just" relabeling.

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 like "permission" for the concept of "allowed by the system to do".

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

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

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

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.

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

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

These words do not capture everything that authorization and authentication entail. As stated several times in this thread, permissions are specific part of what authorization entails, not the entirety.

>Sometimes I feel like we enjoy fancy terms more than we enjoy unambiguous terms

Authorization and authentication are unambiguous.

Could be we just enjoy precision more than anything else.

For lay people, maybe authn and authz are poor words. For those of us working with those words, they're a lot better than login and permission. I don't really want to call a function to get a "permission code" instead of an "authorization code".

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.

permission to use X license... (or whatever license check means in this context)

permission to use at X time...

One can implement different kinds of permissions for a given resource. Including ones related to license or time constraints.

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

If people are too lazy/whatever to use the full word, they are going to be too lazy/whatever to change to a different word entirely.

The only reason to keep using Auth/Auth is because you want to be less easily understood by others. Calling it "renaming" is itself odd to me, if someone said Identity/Permission or Login/Permission, it wouldn't even flag to me as being unusual or non-standard. I'd know exactly what they meant.

You may find that your user account has permission to read the employee salary database. However, you may not be authorized to read that database by corporate policy because you are not a manager. Perusing that database will still get you in trouble, because you aren't authorized to do so, even though your account had the technical permissions to access it.

You may find that you have permissions to screenshot internal databases and post them on facebook, however since you are not authorized to do so by policy, you will be fired.

Etc.

It's true that there are technical enforcement mechanisms, and corporate policies, but it is false that the former must be called permissions, and the latter must be called authorizations. The policies can easily be called either authorization or permission. It is true that we refer to e.g. Unix file permissions, and a corporate policy is more likely to use "authorization" but this is not a semantic difference--the corporate policy would be correct and binding if it used the word permission.

If a fellow employee asks you "do I have permission to do this?" you must say "no" (or alternately "you're not permitted, even though the computer will not enforce that"). Saying "yes" because there is a technical permission would be a very bad idea.

However, for as long as I've been in the business, those terms refer to different things. That is how it is taught in school, how it is referred to in documentation, how you have to understand them when you write your CISSP, how various governing bodies separate and refer to the ideas, etc.

During an audit, if you are asked for your authorization policy and you give them a list of file permissions, you are failing your audit (well, not really, but you'll probably get a scoff and a condescending clarification of what the auditor wants -- and it is never good when an auditor becomes condescending).

In a professional context, permissions are a specific technical enforcement of an authorization policy.

You have authorization - you are allowed to see the file now, from this machine attached to this network in this geographic location using this type of authentication.

"I have permission to see this file, but I can't access it outside the corporate network" said many people lots of times.

"Leadership gave me permission to view this file, but the computer/network doesn't permit me to do that."

No matter what you do here, there isn't a simple solution. It's complex.

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.

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

Here "permission" is defined as an "Operation/Object pair" - for example, read/write/execute access to a particular file. But crucially, there's no user involved (yet). That's where authorization comes in. When a permission becomes associated with a user (in this case via roles), you have authorization.

This sense of the word "permission" has now become very well established in the field of identity and access control.

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

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

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

The first sentence in the article actually highlights a nice "side effect" of the very thing it complains about. Covering "Authentication" and "Authorization" with a single "auth". Convenient for those who understand the concepts and don't need the distinction. Especially since these terms are strongly related and often come together.

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.

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.

Therefore the request is unauthorized because the server wasn't able to authenticate the user. But that's still not consistent with 403 though, so it's not very satisfying.

But this also speaks to one of the nubs of the terminology issue. "Actors" are authenticated, "Actions" are authorized.

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

But I've found that when people have a hard time keeping authentication and authorization straight they are mostly having a problem distinguishing the concepts, not really the terms. I really doubt using alt terminology, which is also already heavily overloaded, is going to help.

Do other folks have different experiences?

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.

I think the complaint is that the the shared prefix/root causes the two words to be less distinct from each other

>> For example, when exactly do you "login" when calling an API with a bearer token? Doesn't work for me.

In my mental model, you "login" to the API when you provide the bearer token.

While I would agree that this is "stretching" the meaning of the word login quite a bit, passing the bearer token serves the same functional purpose as a human keying a UID / PW combo.

Authentication and Authorization are correct and complete terms that have separate but related meanings, personally I don't feel them to be confusing at all.

The entire article feels like whining because the author stubbed his toe against a corner.

Lay people need explaining these concepts using non technical words? Of course, that's what documentation and manuals are for. "WE" are not lay people, and we should understand what their meanings are.

I feel like this is trying to simplify something that can’t be simplified so easily, and perhaps shouldn’t be. The desire to reduce such a complex and broad problem space suggests to me a lack of understanding of what a simplification entails. Using these different words may only present confusion in other directions.

Login isn’t always what authentication is about. In fact, I recently wrote an authentication layer for identifying users based on something that would have been sent to their email, but they don’t exist as users in the system yet. They can’t log in. They don’t even need to in order to utilize this authentication layer. So it isn’t login, yet it’s a form of authentication.

Permissions is a good word I guess, but it’s as specific as authorization. Why change it?

Maybe I like auth because it’s familiar. I am open to new ideas though. This one just doesn’t seem to make sense.

"Logging in" can mean either authentication, authentication+authorization, or authorization depending on context.

Specifically, "logging in" does not need to imply authentication. Example: I "log in" to a public WiFi hotspot using a shared password written on the wall. Yet, there is no authentication taking place.

Login implies the process of obtaining a session by providing some credentials; this is not the same as authenticating, which can be achieved without requiring a session (e.g. bearer token).

I do quite like permissions for authorisation though.

LPAA... Is just not right.