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.
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.
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.
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.
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
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.
> 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
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.
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.
> 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".
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
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
"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.
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.
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".
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.
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.
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.
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)
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.”
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.
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.
362 comments
[ 2.8 ms ] story [ 277 ms ] threadI 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
a12n and a11n, if you will.
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
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.
> If Okta is conflating things on their end
Okta need not conflate anything; a layperson is going to see "Okta is our SSO system" → "Okta provides these things", and there you are.
But groups muddy the water even further. Your SSO system is making authz decisions. If someone (reasonably, and correctly) asks, "can I have permission to use $app?", … and that app assignment is then made in Okta, there you are.
Okta is far from the only such SSO to have such features, but it's also ridiculously widely used.
(I don't know that I like that Okta hands app assignment to administrators, and not users, but such is the case. But things like group or role claims — essentially whatever passes for a modern day directory — that's authz, more or less, since the groups directly dictate.)
To build on top of this point, authentication also includes claims that are not tied to an authorization process, such as user agents or custom request headers, and authentication is often used not to reject access but to output subsets of data (I..e, hide fields from a response, send a specific response doc, etc)
It's as if the whole industry uses the keyword "auth" for good reasons.
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
Really, modern practice has moved past 'log in', sorry.
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.
Yes, we need a NEW standard: https://xkcd.com/927/
Authenticate. Authorize.
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.
Do other folks have different experiences?
Yes, that was the point of using auth.
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".
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.
>> "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?
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.
The conventional flow of current goes from positive terminal to negative. But electrons actually flow from negative terminal to positive.
However, in the typical case, what's moving is electrons, which means the "current" is flowing in the opposite direction of the movement of the electrons. This is stupid and everyone hates it.
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.
In the coordinate system of an atom, the nucleus is at the origin, 0, while the electrons are a positive distance from that core. 0 is not negative, obviously, but it's non-positive.
When terminology is concordant in this way, the topic is easier for a student to grasp. When discordant, harder.
There's little chance for this wart to be remedied, invalidating every paper written up to that point is a bit of a non-starter. But I dislike it nonetheless.
Negating when you move electrons is just one more step, but so is negation within a complex expression in language or programming, and we do try to avoid piling that up.
A "pro" negative? That introduces a whole new confusion.
"Lets review some terms. Hydro. What should you think when you hear the word hydro?"
"Hydrogen?"
"No! Water! Isn't it obvious?"
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.
https://httpd.apache.org/docs/2.4/mod/mod_authn_core.html
https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html
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 ;-)
But using “login” and “permissions” for explaining concepts to general populace is perfectly fine as well.
I know acronyms and stuff but if it creates confusion just use the damn complete word, I don't get why create a problem.
If people are too lazy/whatever to use the full word, they are going to be too lazy/whatever to change to a different word entirely.
The only reason to keep using Auth/Auth is because you want to be less easily understood by others. Calling it "renaming" is itself odd to me, if someone said Identity/Permission or Login/Permission, it wouldn't even flag to me as being unusual or non-standard. I'd know exactly what they meant.
Permissions are a subset of authorization.
I see comments stating that, but no examples.
You may find that your user account has permission to read the employee salary database. However, you may not be authorized to read that database by corporate policy because you are not a manager. Perusing that database will still get you in trouble, because you aren't authorized to do so, even though your account had the technical permissions to access it.
You may find that you have permissions to screenshot internal databases and post them on facebook, however since you are not authorized to do so by policy, you will be fired.
Etc.
It's true that there are technical enforcement mechanisms, and corporate policies, but it is false that the former must be called permissions, and the latter must be called authorizations. The policies can easily be called either authorization or permission. It is true that we refer to e.g. Unix file permissions, and a corporate policy is more likely to use "authorization" but this is not a semantic difference--the corporate policy would be correct and binding if it used the word permission.
If a fellow employee asks you "do I have permission to do this?" you must say "no" (or alternately "you're not permitted, even though the computer will not enforce that"). Saying "yes" because there is a technical permission would be a very bad idea.
However, for as long as I've been in the business, those terms refer to different things. That is how it is taught in school, how it is referred to in documentation, how you have to understand them when you write your CISSP, how various governing bodies separate and refer to the ideas, etc.
During an audit, if you are asked for your authorization policy and you give them a list of file permissions, you are failing your audit (well, not really, but you'll probably get a scoff and a condescending clarification of what the auditor wants -- and it is never good when an auditor becomes condescending).
In a professional context, permissions are a specific technical enforcement of an authorization policy.
You have authorization - you are allowed to see the file now, from this machine attached to this network in this geographic location using this type of authentication.
"I have permission to see this file, but I can't access it outside the corporate network" said many people lots of times.
"Leadership gave me permission to view this file, but the computer/network doesn't permit me to do that."
No matter what you do here, there isn't a simple solution. It's complex.
Using "login" and "permissions" are worse IMO, because they don't catch the entire meaning and complexity of these systems. Authentication means way more than login, and permissions mean very specific things for a small portion of an authorization system.
permission to use X license... (or whatever license check means in this context)
permission to use at X time...
One can implement different kinds of permissions for a given resource. Including ones related to license or time constraints.
I don't think sharing a prefix/root implies that they're the same thing.
Also, I don't think the suggested "permissions" and "login" terminology would work for all AuthN/Z schemes. For example, when exactly do you "login" when calling an API with a bearer token? Doesn't work for me.
I think the complaint is that the the shared prefix/root causes the two words to be less distinct from each other
>> For example, when exactly do you "login" when calling an API with a bearer token? Doesn't work for me.
In my mental model, you "login" to the API when you provide the bearer token.
While I would agree that this is "stretching" the meaning of the word login quite a bit, passing the bearer token serves the same functional purpose as a human keying a UID / PW combo.
Authentication and Authorization are correct and complete terms that have separate but related meanings, personally I don't feel them to be confusing at all.
The entire article feels like whining because the author stubbed his toe against a corner.
Lay people need explaining these concepts using non technical words? Of course, that's what documentation and manuals are for. "WE" are not lay people, and we should understand what their meanings are.
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
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.
And I use those terms in all error messages, documentation, and code. Otherwise I respect the standard.
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.