Instead of 'Auth,' We Should Say 'Permissions' and 'Login' (ntietz.com) 101
The term "auth" is ambiguous, often meaning either authentication (authn) or authorization (authz), which leads to confusion and poor system design. Instead, Nicole Tietz-Sokolskaya, a software engineer at AI market research platform Remesh, argues that the industry adopt the terms "login" for authentication and "permissions" for authorization, as these are clearer and help maintain distinct, appropriate abstractions for each concept. From their blog post: We should always use the most clear terms we have. Sometimes there's not a great option, but here, we have wonderfully clear terms. Those are "login" for authentication and "permissions" for authorization. Both are terms that will make sense with little explanation (in contrast to "authn" and "authz", which are confusing on first encounter) since almost everyone has logged into a system and has run into permissions issues. There are two ways to use "login" here: the noun and the verb form. The noun form is "login", which refers to the information you enter to gain access to the system. And the verb form is "log in", which refers to the action of entering your login to use the system. "Permissions" is just the noun form. To use a verb, you would use "check permissions." While this is long, it's also just... fine? It hasn't been an issue in my experience.
Both of these are abundantly clear even to our peers in disciplines outside software engineering. This to me makes it worth using them from a clarity perspective alone. But then we have the big benefit to abstractions, as well. When we call both by the same word, there's often an urge to combine them into a single module just by dint of the terminology. This isn't necessarily wrong -- there is certainly some merit to put them together, since permissions typically require a login. But it's not necessary, either, and our designs will be stronger if we don't make that assumption and instead make a reasoned choice.
Both of these are abundantly clear even to our peers in disciplines outside software engineering. This to me makes it worth using them from a clarity perspective alone. But then we have the big benefit to abstractions, as well. When we call both by the same word, there's often an urge to combine them into a single module just by dint of the terminology. This isn't necessarily wrong -- there is certainly some merit to put them together, since permissions typically require a login. But it's not necessary, either, and our designs will be stronger if we don't make that assumption and instead make a reasoned choice.
Or, here's an idea (Score:5, Insightful)
The problem isn't the words, it's the shorthand - so how about simply not saying "auth"? If you mean authorization, say "authorization". If you mean authentication, say "authentication".
I mean, if we introduce the term "permissions" then it's simply a matter of time before the "auth" people start saying "perms"... and now we've created new confusing ambiguity between permissions, permitting, and hair styling.
Re: Or, here's an idea (Score:1, Funny)
Re: Or, here's an idea (Score:4, Insightful)
Re: (Score:3)
Indeed. Incidentally, "authorisation" does not even mean "permissions". It does mean deciding whether a specific access is allowed. That can be much simpler and much more complex than "permissions".
Re: Or, here's an idea (Score:3)
We don't need to do anything. It's just a random article but a random person. People should stop feeling pressure to act just because someone, usually a self-proclaimed or, these days, self-righteous expert tells them to change. Some ideas deserve attention. Most of them don't. Move on. Nothing to see here.
Re: (Score:2)
Go look at the normal submission system. This story isn't there.
design. Instead, Nicole Tietz-Sokolskaya, a software engineer at AI market research platform Remesh
See this isn't a story. It's SEO. The confusion between various IAAA components is a well known thing, this guy just pulled a topic out of his hat so he'd have something to attach his name to.
Was going to say the same thing (Score:3, Insightful)
I've always just said "Authentication" or "Authorization" depending on what I meant, almost never would I use the shorthand Auth... I don't see any point in replacing those excellent words which work well.
"Login" also seems like slightly less clear a word.
Re: (Score:2, Interesting)
I agree with renaming for clarity.
However I really only care about authorization, of which authentication is a necessary precondition anyway. Most of the time at least.
Re: (Score:2)
We already have a standard for shortening long names. Thus
* a13n replaces 'authorization', and
* a14n replaces 'authentication'.
both of these are 1 char shorter than authz / authn, so it should greatly simply things.
Re: (Score:3)
"Login" also seems like slightly less clear a word.
It also means something slightly different than "authorization" or "authentication." Use the words that mean what you mean.
Re: (Score:1)
If you're dealing with someone who can't tell what you mean then perhaps you shouldn't hire them.
Jargon exists for a reason.
How about you use the terms that existed long before some marketing droid came up with your entire field? You wouldn't go to work in a pharmacy and then demand they stop using all those Latin abbreviations.
Re: (Score:2)
Yeah, they're too long. I suggest shortening login to log, and permissions to mission.
Re: (Score:3)
If I were that girl's boss, I would be questioning my decision to hire her. She sounds like a new high school graduate who thinks she has stumbled upon an important topic that all of us career programmers have somehow never considered, but she never had a programming class.
We really shouldn't have to be having this conversation, as the solution is exactly what you pointed out: don't use shorthand where the meaning of the shorthand isn't clear. This is covered on the first day of any competent programming cl
Re: (Score:2)
And yet we are having this conversation and this means that someone of the "career programmers" forgot what he learned "on the first day of his competent programming class" and now is butt hurt that the newbie not only a) noticed it but also b) suggested a quick win with words that aren't longer than the maybe unclear shorthand terms.
Re: (Score:2)
No. I'm annoyed that yet another newbie has inflated a simple, non-issue into the status of dramatic problem. It might even be an LLM told to pick some random facet of computer security and pretend like it's a problem.
Re: (Score:2)
Well, however small the issue is, I don't think a blog or social media post is "dramatic". Especially if a fix is proposed that basically free.
It becomes dramatic when people get annoyed because they can't handle ideas for improvements, especially for small obvious stuff that they missed.
My idea: take all the drama out by just saying: "Ahh yes. I'll keep it in mind".
Re: (Score:1)
This was already a solved problem and the author goes out of his way to address the solutions as being inadequate while offering a solution that is itself inadequate.
Authn and authz have a clear meaning to anyone who needs to know what they mean, they can be collectively referred to as "auth" which is fine too. If you don't know the distinction then you shouldn't be messing with permissions.
Login and permissions has its own issues because login is ambiguous with the closely related term that the au
Slashdot is a happy place. (Score:1)
Tbh I'm not sure what other natural languages use.
When the subject is taught anywhere Authorization and Authentication are standard terminology, they're used in NIST publications, academic papers, and standardized across certifications even when they're available in other languages.
I'm not sure he's quite as aware of how deeply entrenched this. Supposing there was a similarly compelling reason to change Internet Protocol to Standard Network Protocol, or network address to network location. He does know full
Re: (Score:1)
So I asked about words in other languages and my friend said "I think there are other words but I don't know what they are."
So sounds like even though there is native terminology it's not often used.
I will admit I often intentionally do use words other than Authentication or Authorization when the distinction is very important and I'm dealing with fairly fresh support people or something. I'm also guilty of using them interchangably when it's not so important and context provides clarity.
Re: (Score:1)
Especially if a fix is proposed that basically free.
but there isnt a problem to fix
Re: (Score:2)
contextualize the problem there. There really is one (1) case initial signon where authorization and authentication may be occurring simultaneously and in that case there is really only one decision being made too, which is, is the subject authorized to continue authenticating. After that point everything really is unambiguously either an authorization or an authentication decision.
Even if you are talking about something like a message or a token - you are going to Authenticate the message, then make an a
Re: (Score:2)
In other words: You don't want any improvements because you have arranged yourself with the problem and mitigated it.
Re: (Score:1)
I tease DarkOx regularly and he's arguably right. Uh this time he's right.
I don't know why anyone is defending the author with their unsupported claims that authn and authz are too confusing when with their next breath he says that we should replace authn with "login" as if that doesn't have its own ambiguities revolving around Identity and Authentication.
Well now that we've cleared that up if DarkOx wants to tell us about appeasing Russia or banning abortions... well I'll be right here.
Re: (Score:2)
>If I were that girl's boss, I would be questioning my decision to hire her.
but . . . but . . . this is the most important technology terminology breakthrough since banning the "master slave flipflop" !
Re: (Score:2)
I definitely remember we had this discussion almost 30 years ago when we were discussing apache module namespaces.
Good to see it is still an unsolved issue.
I have a very original idea, how about we borrow the I18N scheme - use the number of letters between first and last, so we get - A12N and A11N? Much better, eh? :)))
Re: (Score:2)
The issue is having two very similar sounding and looking words in the same domain.
Permitting is I think some American thing to do with building regulation, and a perm is a hair treatment process, so neither are likely to conflict in the computer security space.
Re: (Score:2)
Indeed. That is what I do in my security lectures after explaining the potential for misunderstanding. Solves the problem nicely.
Incidentally, "login" is somewhat orthogonal to "authentication". You can, for example, have login without authentication. Yes, this is a border-case, but it does exist. Anonymous login is a thing, e.g. in FTP. You can also have authentication without login, for example, when a document gets authenticated with a signature or for a more technical example when a DNS response packet
Re: (Score:1)
I would argue that anonymous FTP is still "authentication". You've presented an identity ("anonymous"), and the necessary credentials to verify that identity (none). Saying it's not authentication is like saying zero isn't a number, or an empty list isn't a list.
Re: (Score:3)
Anonymous FTP uses "identification", but there is no proof of that claimed identity, the claim is accepted without further proof. Hence it cannot be authentication.
Re: Or, here's an idea (Score:1)
That is why, when we say auth, we mean both authentication and authorization because they should go hand in hand, if you separate them then they become different concepts that are implemented separately.
The author of this dumb blog post doesnâ(TM)t understand the fact that professionals understand what needs to be done and use short hand inside the biz.
Re:Or, here's an idea (Score:5, Informative)
The industry has already adopted alternative terms: identity and access management (IAM). And unlike "permissions" and "login" these terms accurately represent the scope of the authentication and authorization components.
Re: (Score:1)
At the risk of being pedantic, authentication is a mechanism that allows someone to assume the role of a specific user or context. Authorization is what hands that specific role or context permissions to do stuff, if anything.
A lot of words can be mixed up and it make some sense. Permissions, and rights, for example. ACEs can even be used, but ACEs can be used to deny.
Then, there is the age-old thing. In Windows, it is "logon", in UNIX, it is "login". Other places, it is username or userid.
I can see so
Re: (Score:2)
Because people are lazy. That's a lot of letters to type. It's why we had oddball shorthand like i18n - because typing out internationalization is just too much.
authorization is 13 letters
authentication is 14 letters
Maybe we can just call it a13 and a14 ?
Re: (Score:2)
The problem isn't the words, it's the shorthand - so how about simply not saying "auth"? If you mean authorization, say "authorization". If you mean authentication, say "authentication".
I mean, if we introduce the term "permissions" then it's simply a matter of time before the "auth" people start saying "perms"... and now we've created new confusing ambiguity between permissions, permitting, and hair styling.
Don't we already use "permissions" and "login" to talk "computer" with laypersons?
When it comes to shorthand, typically you're using it with people who will understand how the word is being used in context, so people will know if "auth" is "authentication" or "authorisation". I.E. I've just got the auth to make the changes to the auth system. Keep in mind I'd never say that as I'd sound like a total knob.
Sounds like a bunch of marketing people who have nothing better to do... and will soon be out of a
So LPA instead of AAA? (Score:2)
Re: (Score:2)
Has he considered accounting yet?
Maybe he can call it Reporting and suggest LPR as an acronym so we have less confusion.
'Sup dog, heard you like lpr so I sent your lpr to lpr so you can lpr while you're lpring.
I learned AAA in first year of systems programming and somehow it was OK in the mid 90's.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
If you have to introduce someone, however, I'm not sure I'm going to pay attention to their opinion.
Yeah, I'm not going to pay attention. I usually mean both, as in in both makes sense when handled by a lot of the same logic. Otherwise, the usage is generally clear. Maybe just talk to your colleagues or authors that you read and get them to change. If they won't, or don't want to change, you will have avoided embarrassing yourself on the internet.
Re: Refreshing (Score:2)
Re: (Score:1)
If master and slave bothers like 1% of techies and they suggest something else that has some traction I'll happily use the new lingo as long as they don't have some illwoke freakout on the day I slip up.
Login and permission come with a whole new can of worms to deal with. IAAA ambiguities are typically addressed over and over in their related study materials. Master/Slave is sort of randomly used for a hodgepodge of situations and using something like primary or controller or whatever suffices fine when d
No. (Score:5, Interesting)
The terms Authorization and Authentication are not ambiguous.
This is a contrived problem. If you are not clear which you mean, don't use shorthand.
Re: (Score:3)
The terms Authorization and Authentication are not ambiguous.
This is a contrived problem. If you are not clear which you mean, don't use shorthand.
I would go one step farther, and say that if I say "auth", I likely mean both. I can't even think of an example of authorization that doesn't require some prior authentication of the sender. And most authentication is for the purposes of authorizing something.
So to me, this is like arguing that you shouldn't say "quarter" when you mean "heads" or "tails". They're two sides of the same coin.
Re: (Score:2)
The terms Authorization and Authentication are not ambiguous.
The article doesn't say they are. They say it shouldn't be shortened to "auth" which is ambiguous. To be fair I've never seen the word "auth" used.
Re: (Score:2)
The terms Authorization and Authentication are not ambiguous.
The article doesn't say they are. They say it shouldn't be shortened to "auth" which is ambiguous. To be fair I've never seen the word "auth" used.
I've seen it used all the time in the context of protocols, e.g. "HTTP digest auth". But it is usually obvious what you're talking about from context.
Re: (Score:2)
Except in a few questions posted by (ignorant) people asking how to use it, where have you seen that abbreviation used? How does one spell the associated HTTP header?
Re: (Score:2)
Except in a few questions posted by (ignorant) people asking how to use it, where have you seen that abbreviation used?
Apache configuration file syntax: AuthType Digest
PHP environment variable: PHP_AUTH_DIGEST
How does one spell the associated HTTP header?
Well, the documentation from Mozilla [mozilla.org] says that its syntax is:
Authorization: <auth-scheme> <authorization-parameters>
Re: (Score:2)
HTTP also gets them wrong even in their status code names. 401 Unauthorized actually means unauthenticated.
So maybe that is what prompt for this suggestion, because it is hardly a common misunderstanding.
Re: (Score:2)
Not true.
A 401 response can appear for authenticated users as well. Also, "are you authenticated" is in some cases a valid way to determine authorization.
401 means "you do not have permission to view this content", which by definition means you are unauthorized. That is 100% correct usage. How the authorization attempt was made is irrelevant.
Re: (Score:2)
I don't agree. 403 is the status code for "you - authenticated person - don't have permission to see this content". 401 normally results in the client sending authentication credentials and then the content can be served if the server recognises them.
Re: (Score:3)
The proposed terms are also misleading.
While "permissions" does roughly correspond to "authorization" in common parlance, in a technical setting "permissions" are usually just one abstraction among several that go into implementing authorisation.
As for "login", that is just one application of authentication, involving the creation of some sort of stateful session beyond the login event itself.
Re: (Score:2)
Yes because, when I use sudo, I may be asked to authenticate myself and nobody would call that a "log in".
How in the hell (Score:5, Insightful)
How did this make the live page instead of being voted 'stupid' into oblivion.
Re: (Score:3)
How did this make the live page instead of being voted 'stupid' into oblivion.
Nowadays a significant number of Slashdot stories - including this one - don't seem to have passed through the Firehose at all. So I guess the answer is, "the site owner wanted this story posted"?
Re: (Score:2)
Nah, couldn't be that, or there would be dupes . . .
Sounds like a personal problem (Score:1)
People do tend to overgeneralize their own experience.
This may be a problem in her organization, but I wouldn't assume it's widespread.
your mom (Score:1)
Instead of "your mom" I like to just use "bitch" or "shut the fuck up".
Re: (Score:1)
Your Father has waited so long for this moment.
or maybe... (Score:2)
Or, since "login" doesn't quite mean "authentication" maybe say "authentication" for "authentication".
Re: (Score:3)
I still have a hate boner for the word login. You log on, because that's entering your username and password. It used to mean turn logging on, in other words, let me be a user and log stuff that I do.
Login is a modernization based on learning by context and normal bastardization. I'm not sure that I can disagree with common usage of the word login, but if you're talking about what should be and shouldn't be, and using computer science language, you should be aware enough to address log on versus login if yo
Re: or maybe... (Score:1)
In my experience, "log on" never meant turning logging on. Would that be like "party on"?
Users SUCK at security. (Score:2)
The Top 20 Worst Passwords lists that haven’t changed in decades (literally) prove beyond any doubt that re-defining the problem is going to contribute FUCK ALL to the challenge of “auth”.
I would love to say I can’t even believe here, but people are just THAT fucking ignorant now.
Re: (Score:2)
The reality is that users do not care. They may know better but unless it's their own bank account... It could be an unwanted required hurdle in their way making them irritated as well.
I've studied actually a TB of leaked passwords trying to find something interesting or revealing and all I found is that some obviously unimportant sites had a high number of poor passwords... and that people will just "upgrade" their bad passwords to make them "better." adding 1 or ! for example. Many use a year which may o
We already have names (Score:2)
If you're actually paying attention and using these terms in specs and design, they're already called AuthN and AuthZ. If you don't know enough to know the existing industry terms, changing the terms isn't going to change the fact that you don't understand the difference between them, no matter what names you give them.
Re: We already have names (Score:2)
Yes, but you never know when the clear and unambiguous technical terms might become offensive, so best to have a backup.
Pitty the poor genz physics student learning about advanced and retarded potential.
Re: (Score:2)
Meghhh (Score:2)
AI market research platform Remesh (Score:2)
MicroVM Instead Of Container....? (Score:1)
The ambiguity is a feature, not a bug (Score:1)
When we talk about authentication and authorization, we usually refer to them as a single collection of security precautions. In many contexts, we don't _have_ to distinguish between the two. Every single authentication platform or component, also does authorization, and vice versa. OAuth, MS Identity Server, whatever, they all do both. It's handy to just be able to use one short word to describe the collection of security features.
Login != Authorization (Score:2)
Re: (Score:2)
Re: (Score:2)
I would assume it was a typo, personally.
That said, changing the words associated with a complex topic will not in any way make that topic less complex. If you change it to login/permissions, newbies will start misusing login to mean permissions and vice versa. Never underestimate the ignorance of newbies -- and even other experts at times...
Back to square one.
And permissions can't mean anything else... (Score:2)
Like permissions on an object.
Can we please stop expecting 'my terse term' to match 'your terse term'? Sometimes you need 3 words for clarity. And software creation tools are for computers, not people... that should change.
Makes a lot of sense (Score:2)
Login & Permissions are much better and can be understood instantly, even by a layman. They are simple, clear and are used across a variety of fields. They are also more appropriate than Authentication & Authorization. Permissions implies a list of things that are allowed. Authoriza
What is "auth" and who uses it? (Score:2)
I have not come across this word before. Is this brought to you by the department of lazy speakers who could care less about the English language to the point they can't even muster up an "n't" to make their sentences make sense?
True, but... (Score:2)
"Login" does not capture "authentication" at all. "Login" is a state-change that does not even require authentication. It means establishing a somewhat persistent communication channel that allows the issuing of commands and reception of results. Authentication, on the other hand, is a claim of an identity bolstered with proof of that identity and can happen in contexts that have no connection to "login". For example, a signature can authenticate an email or a binary to be installed.
Hence while I agree the
OAuth2 -- Is it used for auth or auth? Yes. (Score:1)
I agree with this. It is a real problem. The author of the article is not stupid.
The auth-auth confusion has infected the OAuth2 standard. OAuth2 docs say that the "auth" is for authorization, not authentication. But it is used widely for authentication, as it can be used for that also. Sort of. OpenID is an authentication standard built on top of it OAuth (correct me if I'm wrong), but frequently the term OAuth is used instead. Or maybe OpenID is not fully implemented in a particular case and plain
As a technical writer for the last 25 years... (Score:1)
I say authentication when I mean authentication and authorization when I mean authorization.
But I get paid by the character.
It's probably an AI/ML problem (Score:2)
They are probably getting their AI / ML / Language models confused with "auth" and are trying to change the behavior of humans so that the whatever language models they are working on / using has an easier time with that word.
I don't think I have seen "auth" in a formal context and in informal context, it is easy enough to understand what it means from the context. I will not be surprised if whatever they are working on has problems understanding the context.
Overly narrow words... (Score:2)
adopt the terms "login" for authentication and "permissions" for authorization
These other words actually mean something different. Authorization is Not Only permissions, But includes other stuff so calling it permissions could be misleading.
Authentication is actually: Verifying you are who you say you are.
Authorization is actually: Checking your authentication against the requested operation And answer the question: Is who you are by policy Allowed right now To Login and do the thing you are ask
Key? Ignition?? I just want to drive!!! (Score:2)
We used to say triple A... Authentication Authorization and Accounting (think audit trail)
But thats too haaarrrddddd!!! Why is it sooo hhaaarrrd!!! It SHOULD be EASY! *stomps away pouting* (And THIS is a programmer/developer)
And the world get's dumber
sigh
No coffee yet and I'm cranky!
About as useful as the master/slave discussion (Score:1)
How is this ambiguous? In what scenario could you use both words *and* have them lead to different outcomes?
Much like 'knack', I have never been in the scenario where someone believed I was talking about chopping up dead horses when I really meant improvised proficiency, and had that lead to a possibly different outcome in the conversation.
I think this is a getting paid for nonsense consultant.
Re: (Score:2)
How is this ambiguous? In what scenario could you use both words *and* have them lead to different outcomes?
LLMs having trouble parsing this so this would be a AI devs pushing a training agenda
We should immediately switch to using randomly generated words for these use cases
The context resolves all ambiguity and anyone struggling with this is horribly broken
Really? (Score:2)
Only a programmer would be dumb enough to confuse that. Network Eng's do not need that type of hand holding.
We should say (Score:2)
“Fuck off,” and “Eat a dick.”
This is dumb (Score:2)
Perm and Log would be just as confusing as Authfff (Score:2)
This is the silliest rant I have come across this week... Why would anyone compare an abbreviated word with a non-abbreviated word, and then use that as proof that the abbreviation is not as clear as the non-abbreviated word - duh!
Wait till you discover acronyms... the same 3, 4, or 5-letter acronym could mean so many different things... now that is something we should all rail about!
If you want to use the full word, nobody is stopping you... do it for clarity's sake... but for heaven's sake, don't introduc