It’s already universally used in IAM, where the other half of the puzzle is also clear and free from ambiguity: “Access”.
KYC (know your customer) are about removing the ambiguity between you user and their identity....
Identity is who you really are. Be that you as an individual or as a corporation.... In the case of your bank they have a copy of your ID, your SSN, for them identity is what established the account and auth lets you work with it.... AWS might know some members of your company (either by corporate or individual card) but might not know your identity (as an individual) and yet you can still authenticate, because you have been authorized by an identified customer. I can transact with crypto as an authenticated user and NOT be identified.
Iirc, Java or J2EE used “Principal”, which I found super confusing
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/
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.
What does the "auth" module ?
“Permission” and “persistence” have the same prefix but entirely different semantics. They also occur more commonly in everyday life.
AuthN and AuthZ are similar in in spelling, appear in similar contexts, and are less colloquial, making the distinction a lot less clear.
There’s a reason many junior devs use them interchangeably without knowing better.
I think the reason junior devs get them confused is that many junior devs are never taught anything about either in school. But then you just tell the junior dev that they mean different things and in my experience they only need to be told that once.
Ultimately I think it’s fine to use vocabulary.
As a dev you're either building or hooking up to either or both of them. And you know what each requires you to build / hook up to.
As a user, you just care "I put my login/password/api key here, and I get the capability to do several things in that webpage/service/etc". Both auth and the other auth are handed for you.
And if the other dev made an error and confused authorization and authentication you have a problem.
Stupider mistakes have been made and it is a sign of overconfidence if you think you are immune to them.
Yes, primarily I've heard that it is to be avoided in technical discussions...
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.
> “Authorization” comes from “auctor” in Latin, meaning “leader” or “author”
__________
[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.
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?
https://www.google.com/search?q=most+popular+language+in+the...
but the rest of your point is dead on.
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.
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.
Garnishment of wages is garnisheeing, though here I'll agree "garnishing" seems to be acceptable too.
Oversight is a less ambiguous example of a single-word contranym.
Edited to add: Sticking with the context of food, "fasting from food" contradicts someone being a "fast eater."
When I'm at a restaurant and I like everyone I see, I order something "off the menu".
It is, unfortunately, possible for more than one thing to be bad at a time.
I assume you mean “red herring”. Red flag just means a sign that something is wrong.
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.
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.
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.
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.
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?
authz -> perm
So much clearer.
Like remembering when it's spelled "stationary" and when "stationery".
"Still" and "paper" are easier to remember.
Same problem when someone wants to substitute "login" for "authenticate" - not synonyms.
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.
I'm a native speaker and I need to pause for a few hundred milliseconds just to be sure I'm using the right one in a sentence.
What does "unauthenticated" even mean here? You aren't logged in, not logged in isn't a state of "unauthenticated", you haven't given any credentials meaning currently you don't have any authority, so unauthorized makes sense. You can have several sets of credentials and switch between them, not giving them any isn't being in an unauthenticated state its a different thing, and using "unauthorized" in that case makes sense.
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?
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
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.
Every time a cohesive pair of words is redefined, a new JS framework is born.
Better title would be 'instead of authz & authn ...' to make that clear, because it does just sound like they haven't heard of the concept at first.
I have always heard and used authz and authn (pronounced auth-z and auth-n). Bare "auth" typically was used to mean both, but IAM was more clear for that in specific contexts. E.G. you might say someone "authed" to indicate both authentication and authorization, and you might have an IAM team that handles both authentication and authorization.
FWIW, I lead an IAM team.
Real travesty came from OAuth. A system designed to handle authorisation was named after the term for authentication.
Maybe it's better to use less similar words if it's security related.
authn and authz are only clear if used as pair.
In security, anything that is less prone to error is good, so words that are hard to confuse or misspell are good.
The concepts are different so it's not like a dial you are turning to make a measurement, the terms are for different domains
> Why would you type the wrong letter when you mean the other one?
Really? Ignorance, laziness, rushing, fatigue, simple mistakes, etc.
What I think is worse is more letters doesn't save you. I've had some conversations where it has gone like 2–3 round trips before the other end realizes that "not" means not, and they mean … the other way.
Replacing terms - that have been around so long that many systems' behaviors map to them closely - with new terms that don't quite overlap seems wildly more likely to create ambiguity and confusion.
Less error prone means less errors means better results. Better results are good.
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.
login is at best defined as authorization + authentication
but things which are in general referred to as login but only provide authorization are not that rare (e.g. you pass a token to a client)
and logins which to provide authentication but not authorization exist to (but are rare and you probably could always nitpick them out of existence)
Similar the term permission is hugely overloaded due to it's wide usage in more causal most times end user facing documentation. Most times permissions are used in a more generic context, like a user having the permission to do something vs. a request made by a user being authorized to do something.
I mean in the end there is no reason not to use login/permission for end-user facing documentations, causal conversations etc. This terms are "good enough" most times. But if you provide a login library or technical documentation for APIs with complex interactions between authentication and authorization then using login/permission just won't cut it.
Also for AuthN,AuthZ there is no point to use auto completion and there is very very little chance to mistype them as long as you don't confused them. Luckily this kind of mistakes do not fall under the patterns dyslexia causes (especially if you do the capitalization).
If you're new to this concept, then you're new to programming in this space.
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?
Especially non-native English speakers, right.
- 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.
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.
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.
And yet a lot of the devs I work with (I'd even go a say most) can't really explain to you the difference between both concepts and use "auth" as a blanket keyword ; which that word allows since it has the same root.
I think that proposal isn't bad because it makes a distinction using simpler words. I'd also prefer for people to learn that simple difference, but that's what we get.
An analog to this is when I first stumbled upon words like a11y and i18n I had no idea what they meant. Now that I've actually had to deal with internationalization systems and accessibility systems I know very much what they mean, but similar to "auth" they're an umbrella invoking a large number of systems that can all function differently.
this 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
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?
Also, I love how you say that everybody knows the meaning of those words yet you feel compelled to provide the meaning. Doesn't really make a good case in your favour.
I highly doubt laymen would understand the difference when using "authorize" and "authenticate" as opposed to "permission" and "login". I would bet you $100 in bitcoin that most people would understand the latter.
Our current implementations are like this. I'm not convinced this is inherent complexity, though.
It seems like almost all the complexity stems from people trying to create hooks to monetize all the pieces of the process.
Security and usability feel like a second and distant third in importance.
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)
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).
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.
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.
> 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...
In daily life you wouldn't be implementing one without another anyway
A login is an active thing that you do, but systems can authenticate you with things like single sign ons, so that you don’t actually “login” to many of the systems you want to be authorised in.
Similarly permissions are the roles and claims your digital persona carries with it. These grant you permission to resources, but these can be trusted once your persona is authorised.
I was confused and it wasn't until years later that I realized that the similar/identical terms stunted my growth.
But I also think the fact that they both get abbreviated to "auth" also causes a lot of bad mental modeling and poor communication.
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.
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.
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.
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
> can be difficult to understand at first.
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.
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.
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.
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.