"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."
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.
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.
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 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
"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.
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
"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 ?
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.
> 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.
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.
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.
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.
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?
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 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.
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.
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.
> 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.
> 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.
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.
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.
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.
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 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.
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 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
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)
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.
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."
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.
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?
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.
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.
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 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.
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.
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.
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
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.
> "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.
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.
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
> 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".
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.
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.
> 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".
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.
Readit News
Everybody knows what an "authority" is. It means they have power or capability.
Everybody knows what authentic means. Something that is proven to be genuine.
The difference between the two concepts, as they are used in crypto systems are specific, important to get right, and also inherently intertwined, confusing, and subtle. I'm skeptical that changing the words would help.
It's one of the many reasons we have the saying, "Don't roll your own crypto."
Trust and verification are just hard problems.
If something is fast, it moves quickly or not at all. Cocktails can be garnished, but so can wages. Sales or trade of a product could be sanctioned by one country, but sanctioned by another.
I generally think it is a good thing to communicate clearly. Sometimes that means using words differently to explain something. Other times, that means using words the same way as others. I think this is a case of the latter.
Also, I think the idea of "native speaker" is a bit of a red flag. There are plenty of people that speak English from birth but are utterly unintelligible, and there are plenty of people that speak English as a second language who speak more clearly than those.
__________
[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.
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.
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?
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.
https://www.google.com/search?q=most+popular+language+in+the...
but the rest of your point is dead on.
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.
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.
Deleted Comment
Deleted Comment
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.
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.
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.
Every time a cohesive pair of words is redefined, a new JS framework is born.
Deleted Comment
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.
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?
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.
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).
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.
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.
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.
And yet a lot of the devs I work with (I'd even go a say most) can't really explain to you the difference between both concepts and use "auth" as a blanket keyword ; which that word allows since it has the same root.
I think that proposal isn't bad because it makes a distinction using simpler words. I'd also prefer for people to learn that simple difference, but that's what we get.
An analog to this is when I first stumbled upon words like a11y and i18n I had no idea what they meant. Now that I've actually had to deal with internationalization systems and accessibility systems I know very much what they mean, but similar to "auth" they're an umbrella invoking a large number of systems that can all function differently.
This sounds a lot like https://www.azquotes.com/quote/1026562
Sorry, but you're just wrong here. The words are speed bumps at best, and it would help a ton to use more instinctive words for them. Nobody needs to pause and think what login means, and that's not true for authentication.
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.
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.
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?
Deleted Comment
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.
But I also think the fact that they both get abbreviated to "auth" also causes a lot of bad mental modeling and poor communication.
I was confused and it wasn't until years later that I realized that the similar/identical terms stunted my growth.
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
Dead Comment
Dead Comment
In daily life you wouldn't be implementing one without another anyway
Deleted Comment
>> "The canonical solution is to call these "authn" and "authz", the n and z evoking the longer words."
or we could just use the longer words?
>> or could we just use longer words?
Agreed: relabeling, with longer words when necessary, can help.
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?
https://httpd.apache.org/docs/2.4/mod/mod_authn_core.html
https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html
A "pro" negative? That introduces a whole new confusion.
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.
Narcissism is a powerful stimulant ;-)
I personally like saying authnz (authentication and authorization mashed together)
"Login" doesn't really cover token or key based authentication, i.e. service accounts don't "log in" but do require authentication and authorization
I could easily adopt those if I find myself naming middleware again.
I like "permission" for the concept of "allowed by the system to do".
I like "activity" or "actions" for things users have done.
Really, modern practice has moved past 'log in', sorry.
For example, I can log into OpenAI, generate an API key, log out, and then use that key to access their systems across a network
CIAM usually means external facing authN/authZ.. (customer identity and access mgmt)
There's so many terms in this space that are already confusing.
SSO misses the Access (permissions) part, which requires policies constraining the acting identity, the target, and the action to be performed
a12n and a11n, if you will.
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.
These words do not capture everything that authorization and authentication entail. As stated several times in this thread, permissions are specific part of what authorization entails, not the entirety.
>Sometimes I feel like we enjoy fancy terms more than we enjoy unambiguous terms
Authorization and authentication are unambiguous.
Could be we just enjoy precision more than anything else.
For lay people, maybe authn and authz are poor words. For those of us working with those words, they're a lot better than login and permission. I don't really want to call a function to get a "permission code" instead of an "authorization code".
Using "login" and "permissions" are worse IMO, because they don't catch the entire meaning and complexity of these systems. Authentication means way more than login, and permissions mean very specific things for a small portion of an authorization system.
permission to use X license... (or whatever license check means in this context)
permission to use at X time...
I know acronyms and stuff but if it creates confusion just use the damn complete word, I don't get why create a problem.
If people are too lazy/whatever to use the full word, they are going to be too lazy/whatever to change to a different word entirely.
But they are closely related. You can't really have authorization without some form of authentication. Both are tied to some kind of identity. And in some cases, such as SSO, authentication involves authorization from another system.
Also, login is not a good replacement for authentication, because there are forms of authentication that don't involve logging in at all. And often the act of logging in just exchanges one set of authentication credentials (username and password or equivalent) for another, shorter lived, set (token, cookie, etc.)
Finally, one nice property of using authz and authn is that you can use "auth" to mean "authentication and authorization", since the two often go together.
Permissions are rights or privileges, which exist independently of their assignment to particular users.
Authorization, on the other hand, can have two meanings - both of which relate to _assignment_ of permissions to users (preferably via groups or roles):
1. The process of assigning permissions to users, as in "you need to be authorized to do that".
2. The process of confirming whether a user has the necessary permissions to perform some action.
The second meaning can also be referred to as access control (or more precisely, runtime access control). It's what applications typically do after authenticating users. Hence, if you want an alternative to "authorization" in the runtime verification sense, the term "access control" might be appropriate.
On the other hand authN and authZ are perfectly adequate and well-understood.
Since the term "authorization" always relates to a (direct or indirect) binding between permissions and users, it makes no sense to use the term "permissions" as a substitute for "authorization".
Here "permission" is defined as an "Operation/Object pair" - for example, read/write/execute access to a particular file. But crucially, there's no user involved (yet). That's where authorization comes in. When a permission becomes associated with a user (in this case via roles), you have authorization.
This sense of the word "permission" has now become very well established in the field of identity and access control.
The proposed renaming seems like it would solidify the lack of understanding, which would be an undesirable outcome.