Instead of “auth”, we should say “permissions” and “login” | Hacker News Reader

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

ntietz.com

614 pointstambourine_man345 comments

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

I could see an argument for using the less precise terminology for user facing error messages, but certainly not on the technical side.

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

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.

Some time ago authentication was shortened to authn and authorization was shortened to authz. If I had to guess that was to aid people who had to write those words a lot. In that aid, I think they've somewhat lost meaning and just became generalized as "auth". People generally do know there are two steps to auth, are aware of the standards, but when asked to put it in words struggle because of some lexical convergence.

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.

It's not that simple for non-native English speakers, not everyone works in an international team so English is being used on a technical level and you basically have to memorize what those words mean if they dont have similar sounding equivalent in your native language. And there people mess it up or simplify the terms by combining them and it doesn't make sense. And you wouldn't use your native language equivalents because docs are usually in English and we code naming things in English. Using those dumber terms would be much more straightforward for everyone.

> non-native English speakers

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?

Auth means authentication or authorization? that's the dilemma

Sure, so why would we replace the two words that have correct meaning when the real problem is laziness?

We now have autocomplete that could choose the wrong word.

We've had autocomplete that could choose the wrong word for over a decade. And?

The industry has used “authz” and “authn” to disambiguate for decades.

I’ve been working in this industry for decades and this is the first time I made that connection…

you're not alone.

The distinction was already present in Apache2 configs in early 2000's, although there authentication was "auth", and "authorisation" was authz.

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

But then it mostly ended up getting used for authentication anyway, so maybe it was ok.

I can second GP.

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.

One type and you have a problem.

Maybe it's better to use less similar words if it's security related.

How are those pronounced?

You pronounce the last letter as a second syllable: authn is "auth-in" and authz is "auth-zee" (probably "auth-zed" in non-American English).

I've seen https://en.wikipedia.org/wiki/AAA_(computer_security) because authentication, authorization, and accounting (audit trails) need to go together so often. You need to know who they really are and whether they're abusing the system.

And then you someone who uses "auth" for AUTHentication and and authn for AUTHorizatioN.

authn and authz are only clear if used as pair.

AuthN and AuthZ are appropriate and succinct ways to express the concerns when brevity is required

So one wrong letter or wrong auto complete and we have the wrong meaning.

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

Why would you type the wrong letter when you mean the other one? Authentication means proving what something says it is, authorization is allowing someone to do something.

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

While I also agree that authn or authz are perfectly clear,

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

yes but it's also even more important to be precise and correct which login/permission fail to be

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

These are widely-used industry terms that have been used for decades. If that was a problem, surely we would have seen it by now?

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.

Unfortunately that is no obstacle for some - see for example the misguided efforts to replace "master/slave" or "blacklist/whitelist". Those terms are similarly clear and not problematic, but there are people who are insistent that they must be replaced.

No, it is not the case that anything that is less prone to error is good.

Strange take on errors.

Less error prone means less errors means better results. Better results are good.

Getting fewer errors does not mean better results -- sorry, I don't really want to continue this conversation of answering vastly general assertions backed by nothing with counter-assertions backed by nothing. My bad, since I started this way. The real objection I have that takes longer to articulate is that this logic is way too simplistic, broad, and worthless.

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.

AuthZ is troublesome in British English domains where the usual spelling is Authorisation.

100%, this is a standard approach.

If you're new to this concept, then you're new to programming in this space.

Identity and permission are often closely related, and usually auth means both. If we replaced auth with permissions and login, I suspect we would still encapsulate the same overarching concept with one of those two words anyway. E.g. use the login module to add permissions to a user or use the permissions module to authenticate.

Having two almost identical terms that mean completely different things is not a very good idea. Also here you are explaining what the words mean, when "login" and "permission" are immediately obvious. Most people don't speak english natively either.

I don’t really consider making an API call as “logging in”. The term sounds really out of place other than in a few specific contexts.

Indeed. "Logging in" implies some kind of long lasting session. And logging in conceptually only requires "identification" (e.g. via a username) but not necessarily "authentication" (e.g. via a password)

Identification is not necessarily via a username, people can identify you via just knowing how you look or your voice, the method doesn't matter.

The term “Identify” is a lot better in this regard.

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

Access doesn’t cover everything though. But identify seems good

I think they mean use both - identity in place of login/authenticate and access in place of auth

Yeah, but access to me feels like access to records. Not necessarily permissions to do certain actions (in general or to certain records)

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

Principal is Identity not access.

And the third half, “management” verbalizes the action therein.

Also, IAM has a cryptic assertion of ultimate authority: In Hebrew, . . . hayah carries the added weight of representing God himself: Yahweh, “I am.” [0]

https://hebraicthought.org/meaning-of-gods-name-i-am-exodus/

Identity/identify may or may not have anything to do with Login, or Authentication...

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

What could be a difference between identification and authentication? In my understanding they are completely synonymous. I frequently use an IdP (identity provider) to authenticate for web applications.

I think authentication is about proof of identity. Identity can mean a lot of things imo. Applications identify me all the time without me giving them any proof of who I am. This happens in meatspace all the time too. People project identity and we make assumptions about what we observe. We don’t necessarily ask them to verify this identify through mutually agreed upon terms.

Know your customer is something that started in banking and is leaking everywhere.

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.

In some circles "identity" is a term of art. For instance an identity provider maps credentials to user accounts. Those may or may not map to a government-numbered human.

KYC is not so much about removinh ambiguity. It's about risk mitigation and proof. Not only about a specific user, but also the connections of a company or a person. There is also a lot of rules and laws behind against AML and PEP checks.

Identification and authentication are different, though. You identify yourself to a website as a specific user (e.g. using a username) and the website in turn authenticates your claim, i.e. verifies that you are in fact the user you claim to be (e.g. using that user's password).

If you go that route .. your OIDC provider authenticates your claim. The website just trusts some specific OIDC authorities which you must use to create your identity.

If the website in question is using OIDC, sure.

IMO…

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.

I don’t think they are almost identical, they just have the same prefix. “Login” and “permission” each have the same problem: “login” is very similar to “logging”, and “permission” shares a prefix with “persistence” (or permanent). Ultimately software engineering is a broad enough field that we will necessarily have to use similar words to describe the many, many concepts

But authentication and authorization are often used in the same context where confusion is lethal.

Why would it be "lethal"?

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.

Ever heard of a hyperbole?

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.

>Ever heard of a hyperbole?

Yes, primarily I've heard that it is to be avoided in technical discussions...

The real problem is people don't have clear differentiation between authN and authZ. You being you doesn't mean you or they consent to something, those are separate, though very close.

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.

The issue is that they have the same prefix AND that unfortunately this prefix is used to abbreviate both words.

What does the "auth" module ?

We shouldn't use that abbreviation, then.

Given that _AuthN_ and _AuthZ_ are in common technical use, I would expect something handling _Auth_ to work on both _AuthN_ and _AuthZ_.

me, reading thread on hacker news, where a different team that used to build the auth service just transferred ownership of the service to my team, which builds the authz service....

Not a good analogy.

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

Okay fair enough about it not being a perfect analogy.

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.

what's the difference between login and logon?

I believe “login” is the process of actually logging in, or the set of credentials used to log in. “Logon” refers to the act of connecting to something. They’re often used interchangeably, though.

That's because they share the same root auto-, i.e. "self". Because they're related concepts...

Apparently not.

> “Authorization” comes from “auctor” in Latin, meaning “leader” or “author”

https://news.ycombinator.com/item?id=40493073

The wild thing is that they’re apparently from different etymologies. “Authorization” comes from “auctor” in Latin, meaning “leader” or “author”, whereas “authentication” originally comes from the Greek “auto” meaning “self”. There probably was some cross influence that brought them into line though.

I'm going to call IAM "Classics", with "Latin" for identity and "Greek" for access.

You're saying that they are almost identical because they share the first 4 letters.... That's a pretty low bar.

"login" refers to the record of access¹, not the access itself, so it is more properly associated with audit. This dates from the early days² of time-sharing systems when you didn't need a password, you were just saying hi to the computer.

__________

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

offtopic, but: I think when your footnotes themselves need footnotes, there's probably a clearer way to write what you wanted to write. Jumping through multiple levels of nested footnotes is fairly hard to read, at least for me.

Indeed; they are log-structured.

It's most likely not that they needed footnoted footnotes, rather that they wanted them and structured their post on purpose to create them.

I disagree. To authenticate something is to challenge it to prove its identity. Authentication is much broader in scope than "login," even within the narrow domain of computer science. JWT signing, domain certs and so forth fall under the "authN" header and use the same cryptographic tools and techniques... even many forms of user authN don't have a "login" flow.

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?

Most people literally do speak English

https://www.google.com/search?q=most+popular+language+in+the...

but the rest of your point is dead on.

Sorry I don’t understand - the link you posted shows that “most people” actually speak mandarin and Spanish?

Parent provided a poor link by just using a Google search results.

https://www.visualcapitalist.com/top-languages-spoken-in-the...

English is not the most popular 1st spoken language, but it is the most spoken language overall.

1.5B speakers is still not "most people", even if it is the most spoken language. To be clear none of this matters, but there is nothing more irritating than seeing a nitpick of a nitpick that is still wrong.

That makes more sense. Thanks.

If you think two different words having different meanings is difficult, wait 'til you hear about contranyms! English is full of words like these, where context is needed to understand the meaning.

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.

Something can be held fast, but I don't think it is usual English to say that something fixed is fast.

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

Something "made fast" is perfectly reasonable usage for tying it in place.

Yep. And something "made fast" is also perfectly reasonable usage for vastly upgrading its speed. "Fast" can absolutely be a contronym.

I think two-word contranyms are more concrete, like "fight together".

Oversight is a less ambiguous example of a single-word contranym.

I've heard "fast" as a contranym to "moving quickly," referenced as "to fast" or "fasting." ie: not eating at all.

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

"Fasten your seatbelt" doesn't usually mean "twirl it wildly above your head".

When I'm at a restaurant and I don't see anything I like, I just order something "off the menu".

When I'm at a restaurant and I like everyone I see, I order something "off the menu".

So essentially you order off the menu based on your surroundings?

The first is "off-menu", and the second (for which I don't think you meant "everyone") is "from the menu". So, no...

People really do say they “ordered something off the menu” when they found the item on the menu. I believe I could usually distinguish the two meanings if I heard a recording. If the item is not on the menu, the word “off” would be stressed.

In Australian english, "off the menu" is perfectly normal vernacular in non formal settings.

I sanction this comment.

>wait 'til you hear about contranyms! English is full of words like these, where context is needed to understand the meaning.

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

Sanction and nonplus are the most insane examples, because sometimes it's literally not possible to figure out from the context which of the two opposite meanings is intended.

> Also, I think the idea of "native speaker" is a bit of a red flag

I assume you mean “red herring”. Red flag just means a sign that something is wrong.

In the case of “auth”, it stands for two related but often separately managed operational processes.

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.

Except then I won't be able to flip the bozo bit on people who confuse authentication for authorization in conversation...

'permission' might be ok, but 'login' is very imprecise and much more ill defined than authenticate.

If words being similar is truly an issue we would have vastly different languages.

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.

> Most people don't speak english natively either.

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.

Well, in that case, we are all going to have to talk about the difference between a "product manager" and a "project manager" ;)

> Having two almost identical terms that mean completely different things is not a very good idea.

What's the problem of telling apart the task of authenticating users from authorizing their access?

There's already identification and authorization (IAM) which is mostly a backronym.

Identification & Authorisation are a better pairing here than Authentication and Authorisation.

This way, if someone says "Oh yeah we have an auth module on this site" you don't need to immediately disambiguate the statement.

But then "auth" itself is ambiguous. So it might make sense to get rid of the lot. "Identification" is a good word for the first. Perhaps "Permissions" for the second?

authn -> ident

authz -> perm

So much clearer.

Login is not obvious. A login is usual a process step before the main part of the process. That does not fit to an API call which is authenticated using a token.

over many years, I've noticed how it's all about differences that get more subtle and precise on every field. I think this specially after watching this the introduction of https://www.youtube.com/watch?v=OMaYFUm8kQQ

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

Think you’re giving ‘Everybody’ a bit too much credit.

> Everybody knows ...

Especially non-native English speakers, right.

well either they know the language to some functional degree, or they dont.

I can't imagine learning German or some similar language and complaining that their words aren't clear just because I don't speak German fluently enough.

The point OP is making that those words are intuitive for readers (everyone). Knowing language is one thing, but intuitively making sense of similar words in a new context is another. Most non native English speakers think in their own language. Seeing word “authorization” simply doesn’t evoke the link with “authority” in their own language.

The Spanish words are very similar to the English ones:

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

Language families other than romance and germanic exist.

And programmers who work in those languages are more than welcome to use terms that make sense to them! There is zero reason to change terms that are perfectly clear to English speaking programmers simply because not everyone speaks English (or languages where English got its words from).

"Estoy registrándome dentro" (I'm signing myself up) it's totally fine. The problem lies on that the phrase looks like you are signing up first, and not logging in to a previous account. In Spanish you would just say 'enter in your account'.

Saw the headline, found your comment within two seconds, exhaled with relief.

Every time a cohesive pair of words is redefined, a new JS framework is born.

Yeah me too, but then I actually read the (very short) article, which immediately addresses that and not much else.

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.

> inherently intertwined, confusing, and subtle.

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.

Yeah but it's hard to understand unless doing a lot with auth. Indeed "don't roll you own crypto" but you don't need a PhD in Mathematics to roll you own auth. Sometimes it's necessary and even if not, it's good to know what could need work.

Old isn't always better.

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.

I agree and was going to say the same thing, so instead I'll elaborate on another angle. (Also—don't shorten to auth solves the vast majority of this debate.)

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

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.

They are excellent words but easily confused. See for example HTTP 1.0, which uses "unauthorized"/"authorization" to mean "credentials required"/"credentials", which persists in field names and status codes today.

For me as a non-native English speaker, "authorize" and "authenticate" are always pretty unclear as to what exactly they mean in a security context. I don't use it enough for it to stick. I'll actually try to remember "login" and "permissions" as shorthand for getting a feel of what they are. And yes, I've never dug deep in security code/systems, but doesn't that make this even more of a problem instead of less. I should be able to understand what these concepts by themselves want to achieve without having a deep understanding of the technical details or coming into contact with it on a regular basis.

Think of it in a real life context instead of a software context. Let's say you want to go inside a building and there's a bouncer at the entry. By presenting him your ID, he'll be able to authenticate you (determine who you are). Only then, will he decide to authorize you in, or not - depending of your right to do so.

The problem here, I think, is the words, not the concepts.

Like remembering when it's spelled "stationary" and when "stationery".

"Still" and "paper" are easier to remember.

Stationery means more than just paper. I don't think there are any good synonyms for stationery, it's the only word with that exact meaning.

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

The problem is the similarity of the words, not understanding the concepts.

Is it? Or is the problem the similarity of the concepts?

imo it's stupid notion that authentication and authorizations are completely different concepts that were infuriatingly given similar spellings.

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.

They're so unclear that HTTP error codes got them confused. 401 Unauthorized usually actually means Unauthenticated, while 403 Forbidden means Unauthorized.

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.

> Unauthorized usually actually means Unauthenticated

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.

> What does "unauthenticated" even mean here?

That you're not logged in.

> You aren't logged in, not logged in isn't a state of "unauthenticated"

What? Yes it is.

> you haven't given any credentials meaning currently you don't have any authority, so unauthorized makes sense

Ok? Yes, if you are unauthenticated (and authentication is required), then you are also unauthorized. However, the error code is not communicating that you are unauthorized; it is communicating that you need to authenticate, thus unauthenticated is more appropriate.

> You can have several sets of credentials and switch between them

Ok?

> not giving them any isn't being in an unauthenticated state its a different thing

That is exactly what being in an unauthenticated state means. What would you define to be an unauthenticated state otherwise?

While we're at it, let's change 404 from "file not found" to "nothing here." The stream thrown back at you in response to an HTTP request is often not really a file.

Unix would like a word (file) with you :)

401 may or may not be unauthenticated, but it doesn't necessarily mean that. It just means that you do not have the authority to do whatever you were trying to do. A 401 implies that you need to gain authority to do what you want to do and try again[1].

A 403 means that it is simply forbidden. You cannot gain the authority to do what you want to do[2] and has nothing to do with credentials, no matter how nicely you ask.

For example, getting a project in your organization may return 401 (simply ask an admin for access), while getting a project in a different organization may return a 403 (you cannot get access to other organizations, ever).

1: https://www.rfc-editor.org/rfc/rfc9110#name-401-unauthorized

2: https://www.rfc-editor.org/rfc/rfc9110#name-403-forbidden

I think of them like this: Authentication is the act of verifying that you are who you say you are, generally with something you know (password) and ideally with something you have (token, authenticator app, etc.). This lets you log in.

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.

What about "access controls" for the AuthZ side, instead of Permissions?

Wondering HNs collective wisdom on this-- at work we've been using Access Controls on our homepage for awhile- https://www.conductorone.com/ - to the people outside the IAM-geek space does this make more sense?

I like the idea of exposing Roles for selection, and having those roles generally apply to permissions or workflows internally. This tends to work pretty well for many, or even most applications. I can't stand fine-grained access controls in general.

I think you are right, although sometimes other words may be better in some contexts. Also, "auth" can still be used if it is clear from the context or if you really mean both together, since sometimes they do go together and in that case "auth" can make sense. If it does not, then you can use full words such as "authorization", "authentication", etc.

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

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)

Even then, I don't think it's quite the same... I've built several authentication and authorization controls, for the past decade mostly around JWT, but even then, I find more of the formal dedicated systems are often more complex than a given application needs, but it does take some understanding in terms of what to get right and getting what things wrong can be problematic. You can use some tools off the shelf, but may want other bits to be custom.

For example, I've worked on several applications where an external provider winds up sending the user through an adapter to the application itself. So that external roles or groups can map to application roles. Especially if your application may be Azure AD for one client, and Okta for another. And another still may want you to provide something (simple user/password backed).

I agree. I’ve never run into a situation in my professional work as a software engineer where there has been confusion about these two terms.

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.

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

It's probably because the name of the codes is actually wrong. 401 is called "unauthorized" but actually means "unathenticated" in every situation I've seen it used. 403 is called "forbidden" which is fine, but is synonymous with "unauthorized" in this case.

It isn't that the codes are named wrongly. 401 Unauthorized means you don't have permission to access the page, whether you're authenticated or not. 403 Forbidden means you can never access the page, regardless of permissions. This is typical in multi-tenant setups or when a site is never accessible to unauthenticated users. The distinction is subtle but important, and developers often misuse these codes, serving 403 Forbidden for authorization issues instead of indicating a permanent block.

The MDN docs state this about 401[0]:

> Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#cli...

Like others said, 401 Unauthorized really means unauthenticated. Authentication comes before Authorization, both in the process and alphabetically, and 401 comes before 403. Hope that helps.

I mean more that I always have to look it up to double check. But I like the tip to remember by thinking of the sequence and the numerical order. That does help!

I don't really understand the point of using two words

In daily life you wouldn't be implementing one without another anyway

I completely agree with you, I also think that authenticate and authorise carry different meanings than permission and login.

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.

Years and years ago, when I was first learning secure networking, including ssh and ssl, I ran across auth and auth (authentication, authorization).

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

I have implemented auth and auth multiple times in my life, and I'm still unsure which one we are talking about sometimes. Permissions and login might not be the best but they immediately brings clarity

Also, when I forget which is which, or when I’m unsure which of these applies in a given case, I can just say “auth” and let others worry about that.

I came on to say much the same thing: a lot of authorization policies are very basic "is this a request by an authenticated user or service."

But I also think the fact that they both get abbreviated to "auth" also causes a lot of bad mental modeling and poor communication.

"authorization" and "authentication" are poor stupid choice of words.

They are long, not easy to pronounce, sound too similar, have the first 4 and last 5 characters the same, they mean wildly different things and yet get interchangeably used as "authn".

If i give you keys to a room with the number 101 on it, is that authentication or authorization, or none ?

If a gatekeeper says "sorry, invalid auth", what the f does that even mean?

An expired token, is that authentication failure or authorization error?

What about fake token ? A token with valid signature but wrong audience ?

Its such a fu*ing mess.

> They are long, not easy to pronounce, sound too similar, have the first 4 and last 5 characters the same, they mean wildly different things and yet get interchangeably used as "authn".

This is a complaint about the English language. We still use many English words that are confusing. The computer science department is perhaps not the best place to reform an entire human language.

"AuthN" is shorthand for authe N tication.

"AuthZ" is shorthand for authori Z ation.

"AuthN+Z" is shorthand for something that provides both.

> If i give you keys to a room with the number 101 on it, is that authentication or authorization, or none ?

Authorization.

To authenticate is to prove who you are. To authorize is to grant access. The key does not prove who you are, it proves you have access to the room.

> If a gatekeeper says "sorry, invalid auth", what the f does that even mean?

Means either authentication or authorization or both failed. This is a complaint about a stupid programmer who can't communicate properly, not with a word.

Bet you a million dollars they'll output the error "invalid login" when it's actually a permissions issue (user can't log into this site/tenant/group/resource, not because the username or password was wrong, but because they didn't have the right role assigned). Changing the word won't make the programmer make fewer mistakes.

> An expired token, is that authentication failure or authorization error?

Authentication.

'Tokens' are not one thing (many things can be called 'a token' and be used in different ways... again, choose the right term to communicate properly), but generally speaking, 'tokens' are things you use to authenticate your identity, and the backend system matches the authenticated token with the authorized roles.

> What about fake token ? A token with valid signature but wrong audience ?

Authentication. Authentication and/or authorization (depends how your example works).

> Its such a fu*ing mess.

The concepts can be difficult to understand at first. Use them more and they make more sense.

> To authenticate is to prove who you are. To authorize is to grant access.

We should be screaming this type of thing from the rooftops. I struggled so much with the difference until someone said something to this effect. AuthN = who you are, AuthZ = what can you do. People seem to get confused because certain classes of individuals have certain rights and think it's the "who" that's important and not the role

A token can also contain the roles themselves. Though, proper usage of roles as groups of permissions can also go interestingly wrong in practice by many.

    > can be difficult to understand at first.

If a concept is already painful to understand, is it prudent to make the pain worse by choosing words that could be examples of grammatical alliteration?

It it really a computer science department v/s english department thing?

The article suggest better alternative, suggestive words to alleviate the confusion.

My comment rants about the premise of the article - poor choice of words.

we can debate a long time about keys with the label 101 on it being authentication or authorization or none.

mine and OP's point is that a better choice of words can avoid these debates and make the world a little less ambiguous.

> mine and OP's point is that a better choice of words can avoid these debates and make the world a little less ambiguous.

If you changed the words to different ones, we would just be having a different debate, because two words cannot resolve the inherent complexity of the subject matter. It would still be ambiguous because the concepts themselves are too complex to address in two words. You would, however, feel like they were simpler, because you chose simpler words that only cover a small fraction of the overall subject matter. This is a self-deception; you'll feel safer in your understanding of what's going on, but you will still have the same problems when trying to use them in different cases. Call it "login" or "jskjfhskjdf", your experience in doing engineering with them will be the same.

("login" does not encompass everything that is authentication, and "permissions" does not encompass everything that is authorization. there are "authentication permissions" and "authorization permissions", and some systems authenticate without "logging in". so you're still going to be confused later on with this choice of words, even if they had the same definitions as the current words)

  > Call it "login" or "jskjfhskjdf", your experience in doing engineering with them will be the same.

Don't agree. Won't argue.

> yet get interchangeably used as "authn".

maybe a nitpick but no, they're not. everyone I know distinguishes between "auth-N" and "auth-Z". i agree that they sound similar but actually its kinda nice that they all group into "auth" and then subdivide to authN and authZ. i guess this is me disagreeing with TFA.

Colleagues & I have always distinguished them as authC and authZ ... less confusing than authN :)

I do the same in text sometimes, but there's more likelihood of confusion when used verbally unless your accent uses something like "Zed". In most American dialects "C" and "Z" are sometimes hard to distinguish verbally. You start into "C as in cow" and "Z as in zoo" games at which point it is easier to revert back to "authn" and "authz".

Never thought about abbreviating verbally and I never heard anyone doing so, but maybe that's because in Dutch (much like in German) we're used to longer words :D

You're right. i meant to say "auth" being used interchangeably for authn/z

Whatever the terms we use are we should definitely have 2 distinct terms to describe the process of proving you are who you claim to be and the process of determining what you can do once logged into the application.

All two many developers and engineering leaders lump both concepts together as “auth” and falsely assume that both can be handled by their SSO service/ using a jwt.

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?

My experience: a lot of the confusion in technical conversations is due to two parties using the same term for different but related concepts. Relabeling the concepts to clarify the distinction is the right thing to do.

>> or could we just use longer words?

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

Fun parallel: https://inkscape-manuals.readthedocs.io/en/latest/_images/in...

The toolbar is called "tool controls bar," the tool controls bar at the left is called "toolbox," and the toolbox at the right is called "commands bar."

If you asked me I'd say it's 3 toolbars. And why is palette not palette bar?

> And why is palette not palette bar?

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.

For some reason, with both words, I have to stop and think about what the "other auth- word" is so I can be sure I'm thinking of this "auth word" correctly.

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

Seriously, every time. I probably worried I'd remembered it backwards at one point early in my career and have never shaken the habit of double-checking myself on it.

I did the exact same thing when I was reading the post! I had to stop reading and take a good 10 seconds to verify which one was which in my head. I use "auth" all the time as a placeholder for "you need to login to use this". I've never really thought too much about authorization versus authentication because to me, those are just implementation details under the "auth" umbrella.

To put a name to the intuition, it's like verb-vs-noun if I just keep it shortened to "auth"

  * auth (noun) - credentials
  * auth (verb) - with permission, gain access.

:shrug:

I authorize you to be authentic!

Hey, I wish electrons were assigned a positive charge and protons a negative one. Way back when. But oh well now.

Can you explain why switching the names would be better? I don’t get it

I remember some messy conventions in electronics as a reason.

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

By convention, electrical current flows in the direction of the movement of positive charge.

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.

Because what we call electricity is electrons moving. So it would make sense for electrons to have the electric charge.

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.

This seems to warrant an appreciation for the nuances of the electromagnetic field, electric potential, and that electron drift in a conductor isn't really the same as varying potentials in the electromagnetic field.

Electricity is generally defined as a flow of electrical charge(s). Nobody except scientists care to know which way the electrons went because we never run out of them.

Chemists building batteries might disagree with you. They have to understand which direction the electrons flow and which elements they are using have the free electrons to spare.

By definition, chemists are scientists.

In addition to the sibling comments, I have a somewhat esoteric reason to wish that the signs of electric charge were reversed.

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.

Also when you're learning organic chemistry, where you need to mentally push electrons around molecules which are diagrammed in a highly compressed notation, the negative charges add just a bit more to your working-memory load (which might've already been on edge of what you can handle without dropping something) until you've had enough practice to compile the patterns down.

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.

Chemistry was my major, and I considered adding this very point, but wasn't sure I could do a good job of explaining what the problem is. You did a great job there ^_^. Yes: there are positive 'holes' that you push a negative number to and then subtract. This is entirely backward and adds considerable difficulty to an already difficult operation.

Because in an electrical current it is electrons that move (usually, unless you have a hydrogen plasma or something), so since electrons have a negative charge, the direction of the positive current is the opposite of the direction the electrons are flowing.

> and protons a negative one.

A "pro" negative? That introduces a whole new confusion.

It's the Greek "proto-", not the Latinate "pro-".

I had a chemistry professor that tried to teach like that:

"Lets review some terms. Hydro. What should you think when you hear the word hydro?"

"Hydrogen?"

"No! Water! Isn't it obvious?"

Hey, as long as we are rewriting history, we could go with different names too.

Both the names of the things and which one was positive were arbitrarily assigned and I just think some mistakes were made… from a teachability/usability perspective.

Like the original USB inventor not making usb reversible from the start.

Since nobody else has mentioned it... the Apache authn and authz modules

https://httpd.apache.org/docs/2.4/mod/mod_authn_core.html

https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html

> or we could just use the longer words?

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 actually like AuthN and AuthZ as they serve as keywords rather than easy to misinterpret natural language.

If I had to guess, one day the author was having a personal moment where they realized they had been using auth incorrectly in some way, then started a blog post for ranting purposes. During research for the blog they realized they were probably just personally wrong but had invested too much time to just delete the post. And here we are.

Just your usual internet attention seeking I guess.

Narcissism is a powerful stimulant ;-)

"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

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.

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

a12n and a11n, if you will.

which ideally are a11y (accessibility)

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

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

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

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.

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

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.

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.

Especially when English is not your first language. These words are long and easy to mix up

I can empathize with this struggle, but I don't think that warrants changing terminology.

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

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

Authorization code? Do you mean authentication?

No, they probably don't. They probably know exactly what they are saying.

I don't mean authentication. An authorization code is something that is handed out to already authenticated identities.

But how else will I signal my superiority over others if I use clear language???

;)

>login and permission.

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.

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.

Indeed, Authorization includes things like license checks, time of use restrictions, etc.

> Authorization includes things like license checks, time of use restrictions, etc.

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

permission to use at X time...

Of course, if you could just wave your magic wand and change the meaning of commonly understood words, you can make the semantics work. Unfortunately, you can't. In this case, "permission to use at X time" does not have the same meaning as "permission to perform action X".

I don't understand why would a magic wand or semantic gymnastics be required.

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

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.

Agreed. Generally just avoid jargon when you aren't sure the reader knows the lingo.

Because people frequently in English use the abbreviation "auth", which is ambiguous.

So people should not use the abbreviation when it isn't clear. Problem solved, no renaming needed.

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.

Nothing is being renamed. "Permissions" is another common name that dates until at least the 1980s in computing. The suggestion here is to use one common and correct phrase instead of another common and correct phase. Login/Identity are also completely standard.

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.

>The suggestion here is to use one common and correct phrase instead of another common and correct phase

Permissions are a subset of authorization.

Could you please provide examples.

I see comments stating that, but no examples.

Permissions are a technical method which are used to implement and enforce authorization policies. However, authorization policies are not composed of just permission controls.

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.

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

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.

You are correct that it is not a law. If you, in a conversation, were to say "permission" in place of "authorization", you'll broadly be understood.

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 read permission on a file - generally used by humans, and UIs like on Google Drive etc to signify your ability to see a file at all, at some time, some location, from some machine.

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.

The last example just points to two types of permissions coming from different sources.

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

Yep, you could change the currently used meaning of permission to mean two different things, usually granted by two different processes. And you'd have confusion.

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

So the problem is the people not the words.

Tends not to matter, the context usually makes it clear what is being discussed.

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

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

As an example, look at how NIST define "permission" in one of the early RBAC papers: https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6192.pdf

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.

Great info. I think you’ve established that authN and authZ are perfectly adequate but I think the fact you had to dig this up shows they aren't widely understood.

The proposed renaming seems like it would solidify the lack of understanding, which would be an undesirable outcome.

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.

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

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

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

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.

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.

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

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?

The article is specifically arguing against using "auth" or "authn/authz"

"Most places say AuthN and AuthZ" is what the post is arguing against.

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

If you’re looking to reduce confusion, I’d avoid using HTTP status codes in non-standard ways. Yeah it’s unfortunate that HTTP calls 401 “unauthorized”, but it has the meaning of “unauthenticated” everywhere else (e.g. “you have failed to prove who you are”), but basically all devs are familiar with this wart. 402 is “payment required”, using that for errors that should be 401 or 403 according to the HTTP spec is more confusing than just using 401 and 403 in spec compliant ways.

You can sort of convolute a reason why 401 Unauthorized is valid, based on the fact that most systems which control access to resources have a (often implicit) policy that users for whom the identity is not known are not allowed to access anything.

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.

Yeah, I think if they were renaming these response codes today, they’d name them something more like “401 Not Authenticated” and “403 Not Authorized”, but it’s too late for that. And I personally think you can say that either an actor or an action is “not authenticated.”

Sorry, I meant I use 401, not 402.

And I use those terms in all error messages, documentation, and code. Otherwise I respect the standard.

Ah I see. If you mean you’re using 401 for “couldn’t authenticate this request”, and 403 for “you lack permissions to be allowed to do this”, then yeah, that’s standard, spec compliant usage.

- 403: I have it, but you should seek the admin to give you the right permission - 404: I don't even have that (lying)

Also in the http world, the header used for authentication is called “Authorization”

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

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.

As an insecurity person I sort of like the name clash. I’m not smart enough to keep those things separate, so realistically, if I’m giving somebody the ability to authenticate I’m also giving them authorization for normal account stuff.

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.

The solution to authentication and authorization being hard to keep straight is to keep using authentication and authorization?

How is that a solution?

They're distinct words that say exactly what they do. They're only hard to keep straight if you haven't taken a few minutes to understand the underlying concepts (and, in a field of complex and nuanced concepts, these are hardly the most difficult). Replacing widely-used terms with new not-quite-overlapping terms turns 2 things into 4 things and is not a solution to anything.

...the article is about the ambiguity of the word "auth". You're talking about something a bit different.

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.

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

And the other 50% is concentrated power of will.

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.

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

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.

In an activity where words have specific meanings and should be used in their correct place in order to prevent miscommunication of intent or purpose, "stretching the meaning" of a particular technical term can only bring confusion (and bugs).

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.

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

I have never wanted to use them interchangeably.

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

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.

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

I agree.

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.

100%. The problem with an issue like this is that there are people who work in the field and know how complex it is and know all the terms and know no matter what terms you try to boil it down to there will be confusion because you simply cannot properly represent so much stuff in two words, let alone one. Then there are people who sort of work around the edges of such systems but don't really see how complex it is and hence come up with superficially sensible sounding things that will just cause confusion in some other way.

"Most computer systems we interact with have an auth system of some kind."

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.

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.

"login" makes the situation of conflating authentication and authorization worse, not better.

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

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

In traditional security training, you learn the "AAAs" of security - authentication, authorization and accounting (and don't forget the last one!).

It's good to have ways to easily capture the meaning of these words, but permissions and login are implementations that fulfill the requirement of the As, not the As themselves.

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

LPAA... Is just not right.

What about auth9n and auth8n? a12n and a11n? To be compliant with the current belt onion for synthesizing obscure techie jargon.

I sympathise with the author wanting to make the meaning of these more obvious, but login is not a good synonym for authentication.

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.

No, we should say "authentication" and "authorization". I usually shorten the first to "authen." and the second to "authz.". I avoid "auth.", but when I do use it either it's clear from context which I mean or I mean both.

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.

Don't say auth, say authn and authz.

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

You know my co-workers who grew up without English never seem to have all these problems. Almost like bored developers have nothing to do, but wave around their thesaurus. This is free speech and a real opinion please respect it to maintain a good discussion.

I use Identify (who claims is coming, it may be used to decide how to authenticate them), Authenticate (make sure that the above matches the user on file) and Authorize (provide to the application a set of stored permissions for the user)

Authentication is when the bouncer checks your drivers license.

Authorization is when he lets you in the bar.

AuthN can be achieved numerous ways that don’t even closely imply a “login”. The terms we have suffice, it’s the education around them that is sorely lacking.

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.

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

No.

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

Lots of action on this article. I just kind of have this feeling of “how have we survived this long?” about this. It doesn’t seem like that big of a deal.

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.

No. We have the long "authentication" and "authorization" and the abbreviations "AuthN" and "AuthZ".

Or use the industry standard AuthN, AuthZ nomenclature?

The article addresses this. They aren't universal enough and when sound out loud they sound the same, and there are no verb forms.

They aren't universal because folks like the article author keep trying to make fetch happen. Authentication, Authorization, and Accounting (AAA) are bedrock security concepts. They sound fine out loud, and I have no idea why a verb form would be a requirement for an abbreviation.

>> They aren't universal enough

Yes, we need a NEW standard: https://xkcd.com/927/

The beauty of this proposal is that it isn't a new standard -- it's suggesting that we use the already existing words and stop using the less understood acronyms.

authn/z are more abbreviations than acronyms, which come with less organization or domain specific required knowledge, which is the typical complaint of acronyms

> there are no verb forms

Authenticate. Authorize.

Authentify is also valid but obviously leads to even more confusion

Never heard of it.

Just don't use the "auth" contraction for "autorization". Only for authentication. Or not at all.

The system state which grants access to a resource based on a user's credentials is "permissions".

Authentication is the process of establishing belief in the user's credentials.

Authorization is the human assigned permission to a resource which may or may not be reflected by permissions. Incorrectly set permissions can allow unauthorized access to a resource.

E.g. if /etc/shadow is accidentally made rw-r--r--, that doesn't mean everyone is authorized to access the password hashes. Doing so may still violate the organization's IT policy.

We need to nail down what authentication and authorization do on a wide scale before we can pin down better naming. I agree with most of this.

Everyone should use the terminology I prefer.

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'm fine with permissions. Heck, it's what I already say.

Login as the process of logging in, the best interpretation, is still pretty limited: authentication is the validation of a much longer chain of events than that. It may start with login, but it lasts for as long as the service accepts to believe such principal is behind such actions.

To make things me interesting, auth already means authentication to me. I accept it can lead to confusion and a better substitute would be welcome.

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

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.

Instead of plural accesses we should say entitlements

So, uh, when my browser checks that the certificate for a site has a DNS SAN that matches the name I used to access it, is the website "logging in" my browser?

And does a signed S/MIME email "log in" to the MUA that receives it?

Authenticate is a perfect good word, let's keep using that.

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

Honestly, I never allow people to abbreviate. You have to say "authenticate" (who are you) vs "authorize" (what are you allowed to do).

In fact I flag most abbreviations in code, for exactly this reason. We aren't charged by the character, spell it out, future you will always thank you.

What about using `sign`? - sign-up - sign-in - sign-out

Example https://radio4000.com/sign

This doesn't address auth(orization), i.e. "permissions", and it also introduces worse usability for non-native speakers. "Sign in" and "sign up" are hard to distinguish for some demographics (especially non-native speakers) so putting them side by side like that while creating nice symmetry makes it harder to understand.

I think some research by Nielsen twenty-ish years ago suggested using "Sign in"/"Sign out" and "Register". It feels like "Log in"/"Log out" won out on most of the web (e.g. Facebook uses "Log in"/"Log out" and "Sign up").

And script, instead of "app".

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

What? No!

Being able to "login" is a permission (or can be in some systems). We already have authorization and authentication. They are good words, just don't abbreviate them unless you mean both at the same time.

No.

Yes

Nope. On general curmudgeon-y principle. Get off my lawn.

authn, authz for me.

Yeah, no.

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.

Reply on news.ycombinator.com