22 ms·

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

614 points by tambourine_man 2y ago

verdverm 2y ago
"Identity" and "Access" Management (IAM) is pretty standard terminology. I personally like saying authnz (authentication and authorization mashed together) "Login" doesn't really cover token or key based authentication, i.e. service accounts don't "log in" but do require authentication and authorization
- Khaine 2y ago
  The other term you might here is AAA: Authentication, Authorisation, and Accounting
  - verdverm 2y ago
    by Accounting, do you mean Audit Logs?
    - candiddevmike 2y ago
      That is a form of Accounting, yes. There are others though, like metrics, and Accounting is meant to mean all of the recording/telemetry.
      - verdverm 2y ago
        I can see this thread rabbit-holing into logmon terminology :]
    - thebeardisred 2y ago
      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.
  - didacticBuffalo 2y ago
    Came here to say this. Is how i learned it decades ago and the importance of each with Radius.
- spicybbq 2y ago
  > I personally like saying authnz (authentication and authorization mashed together) a12n and a11n, if you will.
  - verdverm 2y ago
    which ideally are a11y (accessibility)
- jameshart 2y ago
  Yes, this. Access control is bigger than just permissions. And identity is still relevant even for anonymous users.
- bsid 2y ago
  Also, IAM usually means SSO solutions for employees i.e. things like Okta/OneLogin.. CIAM usually means external facing authN/authZ.. (customer identity and access mgmt) There's so many terms in this space that are already confusing.
  - verdverm 2y ago
    SSO is really just the Identity part, and one way to prove identity, more conveniently across many systems. SSO misses the Access (permissions) part, which requires policies constraining the acting identity, the target, and the action to be performed
    - deathanatos 2y ago
      No, they're still intertwined, unfortunately. For example, Okta has a notion of whether a user is "authorized" to use the app, so you can end up being directed to Okta, prompted to log in, and then shown an authorization error. Users will often phrase this as some odd form of "not permitted to log into the app". Further, Okta admins control the claims the user presents to the app, and those claims can often have authz implications. A "role" or "group" claim is the most obvious one. I've spent endless time going in circles with Okta administrators who can't clearly delineate these two, or who don't understand what an "app" (Okta's term for a relying party) is, etc.
      - verdverm 2y ago
        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.
        deathanatos 2y ago
        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.)
- chipdart 2y ago
  > "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.
- sandworm101 2y ago
  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.
  - verdverm 2y ago
    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
  - jameshart 2y ago
    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.
    - klabb3 2y ago
      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.
- marcosdumay 2y ago
  "Identity" and "Access" are really good names. I could easily adopt those if I find myself naming middleware again.
  - greggyb 2y ago
    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.
- remram 2y ago
  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.
candiddevmike 2y ago
Or use the industry standard AuthN, AuthZ nomenclature?
- jedberg 2y ago
  The article addresses this. They aren't universal enough and when sound out loud they sound the same, and there are no verb forms.
  - candiddevmike 2y ago
    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.
  - DowagerDave 2y ago
    >> They aren't universal enough Yes, we need a NEW standard: https://xkcd.com/927/ https://xkcd.com/927/
    - jedberg 2y ago
      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.
      - verdverm 2y ago
        authn/z are more abbreviations than acronyms, which come with less organization or domain specific required knowledge, which is the typical complaint of acronyms
  - kube-system 2y ago
    > there are no verb forms Authenticate. Authorize.
zdw 2y ago
Most places I've worked have standardized on AuthN and AuthZ as shortcuts for Authentication (login) and Authorization (permissions). Do other folks have different experiences?
- blatherard 2y ago
  The article is specifically arguing against using "auth" or "authn/authz"
- PKop 2y ago
  "Most places say AuthN and AuthZ" is what the post is arguing against.
1970-01-01 2y ago
90% of development and IT is knowing acronyms and abbreviations. The other half is skills.
- hsdropout 2y ago
  And the other 50% is concentrated power of will.
nailer 2y ago
> Most computer systems we interact with have an auth system of some kind. The problem is, that sentence is at best unclear and at worst nonsense. "Auth" can mean at least two things: authentication or authorization Yes, that was the point of using auth.
tekchip 2y ago
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.
mikl 2y ago
Ah yes, the good old “the jargon for X is confusing, let’s add more jargon”.
bazil376 2y ago
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.
- coffeebeqn 2y ago
  Especially when English is not your first language. These words are long and easy to mix up
  - rockemsockem 2y ago
    I can empathize with this struggle, but I don't think that warrants changing terminology.
- lelanthran 2y ago
  > 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".
  - ghnws 2y ago
    Authorization code? Do you mean authentication?
    - danielmarkbruce 2y ago
      No, they probably don't. They probably know exactly what they are saying.
    - lelanthran 2y ago
      I don't mean authentication. An authorization code is something that is handed out to already authenticated identities.
DowagerDave 2y ago
I don't really get the point of this post. Yes naming things is hard, but the fact that these two words are similar is actually a good thing, despite laypersons getting them confused, because they are both functionally and implementation-wise closely related. The confusion is not going to be solved with trying to relabel the concepts. The author never actually illustrates the harm caused by this confusion either. My guess is they ran into something like installing a package that didn't cover their desired needs, attributed this to the "auth" name and instead of moving on decided to write about it. >> "The canonical solution is to call these "authn" and "authz", the n and z evoking the longer words." or we could just use the longer words?
- billsmithaustin 2y ago
  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.
  - AlienRobot 2y ago
    Fun parallel: https://inkscape-manuals.readthedocs.io/en/latest/_images/interface_areas.png https://inkscape-manuals.readthedocs.io/en/latest/_images/in... The toolbar is called "tool controls bar," the tool controls bar at the left is called "toolbox," and the toolbox at the right is called "commands bar." If you asked me I'd say it's 3 toolbars. And why is palette not palette bar?
    - forkerenok 2y ago
      > 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.
- inanutshellus 2y ago
deleted 2y ago
[deleted]
xyst 2y ago
“authn” and “authz” are sufficient to use between technical people. But using “login” and “permissions” for explaining concepts to general populace is perfectly fine as well.
AbraKdabra 2y ago
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.
- mkroman 2y ago
  Agreed. Generally just avoid jargon when you aren't sure the reader knows the lingo.
- Pxtl 2y ago
  Because people frequently in English use the abbreviation "auth", which is ambiguous.
  - ziddoap 2y ago
    So people should not use the abbreviation when it isn't clear. Problem solved, no renaming needed. If people are too lazy/whatever to use the full word, they are going to be too lazy/whatever to change to a different word entirely.
    - Someone1234 2y ago
      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.
      - ziddoap 2y ago
        >The suggestion here is to use one common and correct phrase instead of another common and correct phase Permissions are a subset of authorization.
mkroman 2y ago
"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.
kissgyorgy 2y ago
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.
- candiddevmike 2y ago
  Indeed, Authorization includes things like license checks, time of use restrictions, etc.
  - hu3 2y ago
    > Authorization includes things like license checks, time of use restrictions, etc. permission to use X license... (or whatever license check means in this context) permission to use at X time...
    - macspoofing 2y ago
      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".
      - hu3 2y ago
        I don't understand why would a magic wand or semantic gymnastics be required. One can implement different kinds of permissions for a given resource. Including ones related to license or time constraints.
efitz 2y ago
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.
- bee_rider 2y ago
  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.
jameshart 2y ago
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.
zxxh 2y ago
You know my co-workers who grew up without English never seem to have all these problems. Almost like bored developers have nothing to do, but wave around their thesaurus. This is free speech and a real opinion please respect it to maintain a good discussion.
badgersnake 2y ago
I lead on the team responsible for auth on our product, and we just go with authN and authZ when we don’t mean both.
mcqueenjordan 2y ago
I prefer AuthN and AuthZ. I don't think sharing a prefix/root implies that they're the same thing. Also, I don't think the suggested "permissions" and "login" terminology would work for all AuthN/Z schemes. For example, when exactly do you "login" when calling an API with a bearer token? Doesn't work for me.
- tanseydavid 2y ago
  >> 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.
  - rangerelf 2y ago
    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.
progx 2y ago
So we are back to the most difficult things in programming: naming things.
sergioisidoro 2y ago
The problem goes way beyond any singular ecosystem and extends to the most basic standards as well. For me one of the most confusing things about this topic is the use of "Unauthorized" in 402 [1], when the dictionary definition is about not having permission and authority to do an action [2]. So in my projects I usually use: - 402 - Unidentified (identification) ou Unauthenticated (Authentic identity) - 403 - Forbidden (permission) [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401 [2] https://www.merriam-webster.com/dictionary/unauthorized https://www.merriam-webster.com/dictionary/unauthorized
- yashap 2y ago
  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.
  - growse 2y ago
    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.
    - yashap 2y ago
      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.”
deleted 2y ago
[deleted]
bongodongobob 2y ago
We do in infra/infosec/sysadmin. Sounds like a dev that just isn't familiar with the territory. That's why we have different departments.
archsurface 2y ago
'"Auth" can mean at least two things: authentication or authorization' - the two words you should be using.
jmsgwd 2y ago
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".
- jmsgwd 2y ago
  As an example, look at how NIST define "permission" in one of the early RBAC papers: https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6192.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6192.pdf Here "permission" is defined as an "Operation/Object pair" - for example, read/write/execute access to a particular file. But crucially, there's no user involved (yet). That's where authorization comes in. When a permission becomes associated with a user (in this case via roles), you have authorization. This sense of the word "permission" has now become very well established in the field of identity and access control.
  - foundart 2y ago
    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.
ratiolat 2y ago
Agree with the article. The worst offender is probably Oauth providing endless confusion to developers and end users
EGreg 2y ago
[flagged]
jmull 2y ago
Isn't there are rather obvious solution to this "problem"? When we need to be clear, let's call authentication and authorization... authentication and authorization.
- spiderice 2y ago
  The solution to authentication and authorization being hard to keep straight is to keep using authentication and authorization? How is that a solution?
  - baronvonsp 2y ago
    They're distinct words that say exactly what they do. They're only hard to keep straight if you haven't taken a few minutes to understand the underlying concepts (and, in a field of complex and nuanced concepts, these are hardly the most difficult). Replacing widely-used terms with new not-quite-overlapping terms turns 2 things into 4 things and is not a solution to anything.
  - jmull 2y ago
    ...the article is about the ambiguity of the word "auth". You're talking about something a bit different. But I've found that when people have a hard time keeping authentication and authorization straight they are mostly having a problem distinguishing the concepts, not really the terms. I really doubt using alt terminology, which is also already heavily overloaded, is going to help.
habitue 2y ago
Sometimes someone just points out the obvious, and it's obviously a good solution. I'm happy to never use authn or authz again, good riddance.
gchamonlive 2y ago
> This is a widespread problem, and it's well known. One common solution, using the terms "authn" and "authz", doesn't solve the problem. And this isn't just confusing, it leads to bad abstractions and general failures! Well, in written language, authn and authz aren't mistakeable. In spoken language, I never heard anyone say authn or authz, but their fully developed versions. And about bad abstractions, I believe that has less to do with bad naming and more to do with the fact that authenticating and permissioning is hard to express, develop and to scale in a secure and reliable way. I think a better use of time is to worry less about how to rename these moving parts and spend more energy studying the pitfalls like the confused deputy problem and how it could apply to your specific domain or use case.
Giorgi 2y ago
And script, instead of "app".
aeonik 2y ago
"Authorize" and "Authenticate" are excellent words. They go back to medieval times and haven't changed meaning too much. Everybody knows what an "authority" is. It means they have power or capability. Everybody knows what authentic means. Something that is proven to be genuine. The difference between the two concepts, as they are used in crypto systems are specific, important to get right, and also inherently intertwined, confusing, and subtle. I'm skeptical that changing the words would help. It's one of the many reasons we have the saying, "Don't roll your own crypto." Trust and verification are just hard problems.
- packetlost 2y ago
  I could see an argument for using the less precise terminology for user facing error messages, but certainly not on the technical side.
- charles_f 2y ago
  > 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.
  - oooyay 2y ago
    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.
netfl0 2y ago
No.
layer8 2y ago
“Login” implies a state change, which “authentication” doesn’t. “Authorization” can refer to a process, which “permissions” doesn’t.
chaos_emergent 2y ago
Maybe instead of overloading the shorthand with two definitions, it's best to just use the actual words.
- steve_adams_86 2y ago
  I agree. I feel like this is trying to simplify something that can’t be simplified so easily, and perhaps shouldn’t be. The desire to reduce such a complex and broad problem space suggests to me a lack of understanding of what a simplification entails. Using these different words may only present confusion in other directions. Login isn’t always what authentication is about. In fact, I recently wrote an authentication layer for identifying users based on something that would have been sent to their email, but they don’t exist as users in the system yet. They can’t log in. They don’t even need to in order to utilize this authentication layer. So it isn’t login, yet it’s a form of authentication. Permissions is a good word I guess, but it’s as specific as authorization. Why change it? Maybe I like auth because it’s familiar. I am open to new ideas though. This one just doesn’t seem to make sense.
  - danielmarkbruce 2y ago
    100%. The problem with an issue like this is that there are people who work in the field and know how complex it is and know all the terms and know no matter what terms you try to boil it down to there will be confusion because you simply cannot properly represent so much stuff in two words, let alone one. Then there are people who sort of work around the edges of such systems but don't really see how complex it is and hence come up with superficially sensible sounding things that will just cause confusion in some other way.
deleted 2y ago
[deleted]
WhitneyLand 2y ago
This article took some time to think through, reason about and write, likely with years of experience as a prerequisite. Some articles/proposals like this are beyond what current AI could offer, but it’s interesting to see which ones. Asking Gpt4o, it gives: Authentication: Verify Authenticate Login Authorization: Authorize Permission Access So in this case, it was able to offer the same suggestions as the author as well as some of those from the comments below.
steve_adams_86 2y ago
I think this only works in limited versions of these auth systems. If that’s what you want, great. Some packages for various languages already exist for this purpose. They’re incomplete auth systems, though. There are more modes of authentication than logging a user into a system or referencing their proof of authentication after login. It’s certainly the most common use case, but authentication can occur using other forms of proof that you’re willing to trust. For example, someone in your system invites people to do something via email. Once these people authenticate by entering a code sent to their email address, you trust that they can access a file based on a cookie you’ve set. However, they are not logged in because they don’t have an account. You would not do this with a login system. You’d do it with an authentication system.
deleted 2y ago
[deleted]
iandanforth 2y ago
Totally agree with this article and I'll try to use these words.
spenceryonce 2y ago
Yes
treflop 2y ago
Permissions to me is about setting a policy and authorization is applying that policy. I have never wanted to use them interchangeably.
macspoofing 2y ago
I get what you're doing, but the problem is that "login" and "permissions" are ambiguous in the context of Identity Management. For example, "Delete-User" is a permission that defines some 'permitted action', but it does not imply "Administrator" role or a set of policies that should be governing access to some resources. So by trying to fix one semantic issue, you're introducing a bunch of other ones.
chefandy 2y ago
Between dev and administration/ops work, I spent a couple of decades in the deep end of the tech pool. As we know, it's packed with layers of interconnected archaic, arbitrary and confusing terminology. I understand the resistance to renaming things – the cognitive overhead of learning new terms is real. However, when you remove decades-irrelevant technical limitations and contrived entomological justification, the reason for sticking to old, confusing names often boils down to "because I already know it." Many feel learning it all has earned them this machismo-driven badge-of-nerd-honor, and people advocating for more straightforward terminology are often viewed as weak, lazy, or incompetent. That's convenient for us, but hindering future generations and confusing non-technical users has a cost. For a field so focused on progress, this resistance to improving terminology is strange. While I don't advocate for constant change, or change for its own sake, we should challenge "because, that's the way it's always been" as a justification for not making things better.
potus50 2y ago
Honestly, Im tired of people telling me how to talk. What if instead of policing language we educate people on the differences between authentication and authorization and best practices for implementation? I think you’re onto the problem, but artificial language enforcement isn’t going to fix it.
oaiey 2y ago
I do not like it. AAAA is a good abbreviation for the necessary principles authentication, authorization, access and audit. LPAA... Is just not right.
tracerbulletx 2y ago
[flagged]
deleted 2y ago
[deleted]
unixhero 2y ago
Instead of plural accesses we should say entitlements
mic_check_123 2y ago
Authentication is when the bouncer checks your drivers license. Authorization is when he lets you in the bar. AuthN can be achieved numerous ways that don’t even closely imply a “login”. The terms we have suffice, it’s the education around them that is sorely lacking.
thayne 2y ago
> 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.
pseudocomposer 2y ago
I think it should be “authentication” and “permissions.” There’s pretty much no word in the English language to describe login/account creation/etc than “authentication.” The word “login” is a poor substitute. There are no good synonyms for “authentication” that encompass all its applications in computer systems. Meanwhile, there are already lots of synonyms used for “permissions.” Given the abundance of these, and the lack of synonyms for “authentication,” choosing “authorization” to describe permissions is, frankly, an asinine decision. It adds unnecessary cognitive overhead for everyone. (That’s not to say there’s no place for, say, Unauthorized responses, etc. Just that we should be calling the topic “permissions” or really anything other than “authorization.”)
brhsagain 2y ago
I've always heard "auth" to mean authentication and "perms" to mean authorization.
deleted 2y ago
[deleted]
libria 2y ago
We carry a physical analog of this in real life: work badge. My policy-enforced visible picture identifies who I am and that I match that photo and also gatekeeps me into and out of places I'm allowed to enter. > terminology implies that the two concepts, authentication and authorization, are more closely related than they are ... There are some links ... because what you can do is tied to who you are. But they're also very different AuthZ being entirely dependent on AuthN is not "some links". That's an unbreakable dependency. I can agree that these two words being a single letter apart are easy to conflate though. But as they are related, we're more likely to increase training/education around the concept rather than rename them.
slackfan 2y ago
Nope. On general curmudgeon-y principle. Get off my lawn.
ngc6677 2y ago
What about using `sign`? - sign-up - sign-in - sign-out Example https://radio4000.com/sign https://radio4000.com/sign
- hnbad 2y ago
  This doesn't address auth(orization), i.e. "permissions", and it also introduces worse usability for non-native speakers. "Sign in" and "sign up" are hard to distinguish for some demographics (especially non-native speakers) so putting them side by side like that while creating nice symmetry makes it harder to understand. I think some research by Nielsen twenty-ish years ago suggested using "Sign in"/"Sign out" and "Register". It feels like "Log in"/"Log out" won out on most of the web (e.g. Facebook uses "Log in"/"Log out" and "Sign up").
NovemberWhiskey 2y ago
So, uh, when my browser checks that the certificate for a site has a DNS SAN that matches the name I used to access it, is the website "logging in" my browser? And does a signed S/MIME email "log in" to the MUA that receives it? Authenticate is a perfect good word, let's keep using that.
dagss 2y ago
Don't say auth, say authn and authz.
MattPalmer1086 2y ago
I sympathise with the author wanting to make the meaning of these more obvious, but login is not a good synonym for authentication. Login implies the process of obtaining a session by providing some credentials; this is not the same as authenticating, which can be achieved without requiring a session (e.g. bearer token). I do quite like permissions for authorisation though.
deleted 2y ago
[deleted]
valenterry 2y ago
What? No! Being able to "login" is a permission (or can be in some systems). We already have authorization and authentication. They are good words, just don't abbreviate them unless you mean both at the same time.
debuggerpk 2y ago
authn, authz for me.
BrandoElFollito 2y ago
I use Identify (who claims is coming, it may be used to decide how to authenticate them), Authenticate (make sure that the above matches the user on file) and Authorize (provide to the application a set of stored permissions for the user)
tripa 2y ago
I'm fine with permissions. Heck, it's what I already say. Login, no, just no. Login is ambiguous to begin with, is it the action or the user identifier? Login as the process of logging in, the best interpretation, is still pretty limited: authentication is the validation of a much longer chain of events than that. It may start with login, but it lasts for as long as the service accepts to believe such principal is behind such actions. Login as username is IMHO the most common use of the word, and most obviously the wrong one to mean authentication. To make things me interesting, auth already means authentication to me. I accept it can lead to confusion and a better substitute would be welcome.
dinkumthinkum 2y ago
Lots of action on this article. I just kind of have this feeling of “how have we survived this long?” about this. It doesn’t seem like that big of a deal.
throwaway984393 2y ago
[dead]
bytearray 2y ago
Everyone should use the terminology I prefer.
dboreham 2y ago
No.
_factor 2y ago
We need to nail down what authentication and authorization do on a wide scale before we can pin down better naming. I agree with most of this.
bitwize 2y ago
What about auth9n and auth8n? a12n and a11n? To be compliant with the current belt onion for synthesizing obscure techie jargon.
3np 2y ago
"login" makes the situation of conflating authentication and authorization worse, not better. "Logging in" can mean either authentication, authentication+authorization, or authorization depending on context. Specifically, "logging in" does not need to imply authentication. Example: I "log in" to a public WiFi hotspot using a shared password written on the wall. Yet, there is no authentication taking place.
nikolay 2y ago
No. We have the long "authentication" and "authorization" and the abbreviations "AuthN" and "AuthZ".
balex 2y ago
"Most computer systems we interact with have an auth system of some kind." The first sentence in the article actually highlights a nice "side effect" of the very thing it complains about. Covering "Authentication" and "Authorization" with a single "auth". Convenient for those who understand the concepts and don't need the distinction. Especially since these terms are strongly related and often come together.
sixdimensional 2y ago
In traditional security training, you learn the "AAAs" of security - authentication, authorization and accounting (and don't forget the last one!). It's good to have ways to easily capture the meaning of these words, but permissions and login are implementations that fulfill the requirement of the As, not the As themselves.
Justsignedup 2y ago
Honestly, I never allow people to abbreviate. You have to say "authenticate" (who are you) vs "authorize" (what are you allowed to do). In fact I flag most abbreviations in code, for exactly this reason. We aren't charged by the character, spell it out, future you will always thank you.
cryptonector 2y ago
No, we should say "authentication" and "authorization". I usually shorten the first to "authen." and the second to "authz.". I avoid "auth.", but when I do use it either it's clear from context which I mean or I mean both.
HeavyStorm 2y ago
Yeah, no.

"Identity" and "Access" Management (IAM) is pretty standard terminology. I personally like saying authnz (authentication and authorization mashed together) "Login" doesn't really cover token or key based authentication, i.e. service accounts don't "log in" but do require authentication and authorization

Khaine 2y ago
The other term you might here is AAA: Authentication, Authorisation, and Accounting
- verdverm 2y ago
  by Accounting, do you mean Audit Logs?
  - candiddevmike 2y ago
    That is a form of Accounting, yes. There are others though, like metrics, and Accounting is meant to mean all of the recording/telemetry.
    - verdverm 2y ago
      I can see this thread rabbit-holing into logmon terminology :]
  - thebeardisred 2y ago
    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.
- didacticBuffalo 2y ago
  Came here to say this. Is how i learned it decades ago and the importance of each with Radius.
spicybbq 2y ago
> I personally like saying authnz (authentication and authorization mashed together) a12n and a11n, if you will.
- verdverm 2y ago
  which ideally are a11y (accessibility)
jameshart 2y ago
Yes, this. Access control is bigger than just permissions. And identity is still relevant even for anonymous users.
bsid 2y ago
Also, IAM usually means SSO solutions for employees i.e. things like Okta/OneLogin.. CIAM usually means external facing authN/authZ.. (customer identity and access mgmt) There's so many terms in this space that are already confusing.
- verdverm 2y ago
  SSO is really just the Identity part, and one way to prove identity, more conveniently across many systems. SSO misses the Access (permissions) part, which requires policies constraining the acting identity, the target, and the action to be performed
  - deathanatos 2y ago
    No, they're still intertwined, unfortunately. For example, Okta has a notion of whether a user is "authorized" to use the app, so you can end up being directed to Okta, prompted to log in, and then shown an authorization error. Users will often phrase this as some odd form of "not permitted to log into the app". Further, Okta admins control the claims the user presents to the app, and those claims can often have authz implications. A "role" or "group" claim is the most obvious one. I've spent endless time going in circles with Okta administrators who can't clearly delineate these two, or who don't understand what an "app" (Okta's term for a relying party) is, etc.
    - verdverm 2y ago
      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.
      - deathanatos 2y ago
        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.)
chipdart 2y ago
> "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.
sandworm101 2y ago
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.
- verdverm 2y ago
  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
- jameshart 2y ago
  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.
  - klabb3 2y ago
    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.
marcosdumay 2y ago
"Identity" and "Access" are really good names. I could easily adopt those if I find myself naming middleware again.
- greggyb 2y ago
  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.
remram 2y ago
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.

candiddevmike 2y ago

Or use the industry standard AuthN, AuthZ nomenclature?

jedberg 2y ago
The article addresses this. They aren't universal enough and when sound out loud they sound the same, and there are no verb forms.
- candiddevmike 2y ago
  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.
- DowagerDave 2y ago
  >> They aren't universal enough Yes, we need a NEW standard: https://xkcd.com/927/ https://xkcd.com/927/
  - jedberg 2y ago
    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.
    - verdverm 2y ago
      authn/z are more abbreviations than acronyms, which come with less organization or domain specific required knowledge, which is the typical complaint of acronyms
- kube-system 2y ago
  > there are no verb forms Authenticate. Authorize.

zdw 2y ago

Most places I've worked have standardized on AuthN and AuthZ as shortcuts for Authentication (login) and Authorization (permissions). Do other folks have different experiences?

blatherard 2y ago
The article is specifically arguing against using "auth" or "authn/authz"
PKop 2y ago
"Most places say AuthN and AuthZ" is what the post is arguing against.

1970-01-01 2y ago

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

hsdropout 2y ago
And the other 50% is concentrated power of will.

nailer 2y ago

> Most computer systems we interact with have an auth system of some kind. The problem is, that sentence is at best unclear and at worst nonsense. "Auth" can mean at least two things: authentication or authorization Yes, that was the point of using auth.

tekchip 2y ago

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.

mikl 2y ago

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

bazil376 2y ago

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.

coffeebeqn 2y ago
Especially when English is not your first language. These words are long and easy to mix up
- rockemsockem 2y ago
  I can empathize with this struggle, but I don't think that warrants changing terminology.
lelanthran 2y ago
> 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".
- ghnws 2y ago
  Authorization code? Do you mean authentication?
  - danielmarkbruce 2y ago
    No, they probably don't. They probably know exactly what they are saying.
  - lelanthran 2y ago
    I don't mean authentication. An authorization code is something that is handed out to already authenticated identities.

DowagerDave 2y ago

I don't really get the point of this post. Yes naming things is hard, but the fact that these two words are similar is actually a good thing, despite laypersons getting them confused, because they are both functionally and implementation-wise closely related. The confusion is not going to be solved with trying to relabel the concepts. The author never actually illustrates the harm caused by this confusion either. My guess is they ran into something like installing a package that didn't cover their desired needs, attributed this to the "auth" name and instead of moving on decided to write about it. >> "The canonical solution is to call these "authn" and "authz", the n and z evoking the longer words." or we could just use the longer words?

billsmithaustin 2y ago
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.
- AlienRobot 2y ago
  Fun parallel: https://inkscape-manuals.readthedocs.io/en/latest/_images/interface_areas.png https://inkscape-manuals.readthedocs.io/en/latest/_images/in... The toolbar is called "tool controls bar," the tool controls bar at the left is called "toolbox," and the toolbox at the right is called "commands bar." If you asked me I'd say it's 3 toolbars. And why is palette not palette bar?
  - forkerenok 2y ago
    > 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.
inanutshellus 2y ago

deleted 2y ago

[deleted]

xyst 2y ago

“authn” and “authz” are sufficient to use between technical people. But using “login” and “permissions” for explaining concepts to general populace is perfectly fine as well.

AbraKdabra 2y ago

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.

mkroman 2y ago
Agreed. Generally just avoid jargon when you aren't sure the reader knows the lingo.
Pxtl 2y ago
Because people frequently in English use the abbreviation "auth", which is ambiguous.
- ziddoap 2y ago
  So people should not use the abbreviation when it isn't clear. Problem solved, no renaming needed. If people are too lazy/whatever to use the full word, they are going to be too lazy/whatever to change to a different word entirely.
  - Someone1234 2y ago
    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.
    - ziddoap 2y ago
      >The suggestion here is to use one common and correct phrase instead of another common and correct phase Permissions are a subset of authorization.

mkroman 2y ago

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

kissgyorgy 2y ago

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.

candiddevmike 2y ago
Indeed, Authorization includes things like license checks, time of use restrictions, etc.
- hu3 2y ago
  > Authorization includes things like license checks, time of use restrictions, etc. permission to use X license... (or whatever license check means in this context) permission to use at X time...
  - macspoofing 2y ago
    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".
    - hu3 2y ago
      I don't understand why would a magic wand or semantic gymnastics be required. One can implement different kinds of permissions for a given resource. Including ones related to license or time constraints.

efitz 2y ago

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.

bee_rider 2y ago
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.

jameshart 2y ago

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.

zxxh 2y ago

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

badgersnake 2y ago

I lead on the team responsible for auth on our product, and we just go with authN and authZ when we don’t mean both.

mcqueenjordan 2y ago

I prefer AuthN and AuthZ. I don't think sharing a prefix/root implies that they're the same thing. Also, I don't think the suggested "permissions" and "login" terminology would work for all AuthN/Z schemes. For example, when exactly do you "login" when calling an API with a bearer token? Doesn't work for me.

tanseydavid 2y ago
>> 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.
- rangerelf 2y ago
  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.

progx 2y ago

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

sergioisidoro 2y ago

The problem goes way beyond any singular ecosystem and extends to the most basic standards as well. For me one of the most confusing things about this topic is the use of "Unauthorized" in 402 [1], when the dictionary definition is about not having permission and authority to do an action [2]. So in my projects I usually use: - 402 - Unidentified (identification) ou Unauthenticated (Authentic identity) - 403 - Forbidden (permission) [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401 [2] https://www.merriam-webster.com/dictionary/unauthorized https://www.merriam-webster.com/dictionary/unauthorized

yashap 2y ago
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.
- growse 2y ago
  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.
  - yashap 2y ago
    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.”

deleted 2y ago

[deleted]

bongodongobob 2y ago

We do in infra/infosec/sysadmin. Sounds like a dev that just isn't familiar with the territory. That's why we have different departments.

archsurface 2y ago

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

jmsgwd 2y ago

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

jmsgwd 2y ago
As an example, look at how NIST define "permission" in one of the early RBAC papers: https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6192.pdf https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6192.pdf Here "permission" is defined as an "Operation/Object pair" - for example, read/write/execute access to a particular file. But crucially, there's no user involved (yet). That's where authorization comes in. When a permission becomes associated with a user (in this case via roles), you have authorization. This sense of the word "permission" has now become very well established in the field of identity and access control.
- foundart 2y ago
  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.

ratiolat 2y ago

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

EGreg 2y ago

[flagged]

jmull 2y ago

Isn't there are rather obvious solution to this "problem"? When we need to be clear, let's call authentication and authorization... authentication and authorization.

spiderice 2y ago
The solution to authentication and authorization being hard to keep straight is to keep using authentication and authorization? How is that a solution?
- baronvonsp 2y ago
  They're distinct words that say exactly what they do. They're only hard to keep straight if you haven't taken a few minutes to understand the underlying concepts (and, in a field of complex and nuanced concepts, these are hardly the most difficult). Replacing widely-used terms with new not-quite-overlapping terms turns 2 things into 4 things and is not a solution to anything.
- jmull 2y ago
  ...the article is about the ambiguity of the word "auth". You're talking about something a bit different. But I've found that when people have a hard time keeping authentication and authorization straight they are mostly having a problem distinguishing the concepts, not really the terms. I really doubt using alt terminology, which is also already heavily overloaded, is going to help.

habitue 2y ago

Sometimes someone just points out the obvious, and it's obviously a good solution. I'm happy to never use authn or authz again, good riddance.

gchamonlive 2y ago

> This is a widespread problem, and it's well known. One common solution, using the terms "authn" and "authz", doesn't solve the problem. And this isn't just confusing, it leads to bad abstractions and general failures! Well, in written language, authn and authz aren't mistakeable. In spoken language, I never heard anyone say authn or authz, but their fully developed versions. And about bad abstractions, I believe that has less to do with bad naming and more to do with the fact that authenticating and permissioning is hard to express, develop and to scale in a secure and reliable way. I think a better use of time is to worry less about how to rename these moving parts and spend more energy studying the pitfalls like the confused deputy problem and how it could apply to your specific domain or use case.

Giorgi 2y ago

And script, instead of "app".

aeonik 2y ago

"Authorize" and "Authenticate" are excellent words. They go back to medieval times and haven't changed meaning too much. Everybody knows what an "authority" is. It means they have power or capability. Everybody knows what authentic means. Something that is proven to be genuine. The difference between the two concepts, as they are used in crypto systems are specific, important to get right, and also inherently intertwined, confusing, and subtle. I'm skeptical that changing the words would help. It's one of the many reasons we have the saying, "Don't roll your own crypto." Trust and verification are just hard problems.

packetlost 2y ago
I could see an argument for using the less precise terminology for user facing error messages, but certainly not on the technical side.
charles_f 2y ago
> 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.
- oooyay 2y ago
  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.

netfl0 2y ago

No.

layer8 2y ago

“Login” implies a state change, which “authentication” doesn’t. “Authorization” can refer to a process, which “permissions” doesn’t.

chaos_emergent 2y ago

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

steve_adams_86 2y ago
I agree. I feel like this is trying to simplify something that can’t be simplified so easily, and perhaps shouldn’t be. The desire to reduce such a complex and broad problem space suggests to me a lack of understanding of what a simplification entails. Using these different words may only present confusion in other directions. Login isn’t always what authentication is about. In fact, I recently wrote an authentication layer for identifying users based on something that would have been sent to their email, but they don’t exist as users in the system yet. They can’t log in. They don’t even need to in order to utilize this authentication layer. So it isn’t login, yet it’s a form of authentication. Permissions is a good word I guess, but it’s as specific as authorization. Why change it? Maybe I like auth because it’s familiar. I am open to new ideas though. This one just doesn’t seem to make sense.
- danielmarkbruce 2y ago
  100%. The problem with an issue like this is that there are people who work in the field and know how complex it is and know all the terms and know no matter what terms you try to boil it down to there will be confusion because you simply cannot properly represent so much stuff in two words, let alone one. Then there are people who sort of work around the edges of such systems but don't really see how complex it is and hence come up with superficially sensible sounding things that will just cause confusion in some other way.

deleted 2y ago

[deleted]

WhitneyLand 2y ago

This article took some time to think through, reason about and write, likely with years of experience as a prerequisite. Some articles/proposals like this are beyond what current AI could offer, but it’s interesting to see which ones. Asking Gpt4o, it gives: Authentication: Verify Authenticate Login Authorization: Authorize Permission Access So in this case, it was able to offer the same suggestions as the author as well as some of those from the comments below.

steve_adams_86 2y ago

I think this only works in limited versions of these auth systems. If that’s what you want, great. Some packages for various languages already exist for this purpose. They’re incomplete auth systems, though. There are more modes of authentication than logging a user into a system or referencing their proof of authentication after login. It’s certainly the most common use case, but authentication can occur using other forms of proof that you’re willing to trust. For example, someone in your system invites people to do something via email. Once these people authenticate by entering a code sent to their email address, you trust that they can access a file based on a cookie you’ve set. However, they are not logged in because they don’t have an account. You would not do this with a login system. You’d do it with an authentication system.

deleted 2y ago

[deleted]

iandanforth 2y ago

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

spenceryonce 2y ago

Yes

treflop 2y ago

Permissions to me is about setting a policy and authorization is applying that policy. I have never wanted to use them interchangeably.

macspoofing 2y ago

I get what you're doing, but the problem is that "login" and "permissions" are ambiguous in the context of Identity Management. For example, "Delete-User" is a permission that defines some 'permitted action', but it does not imply "Administrator" role or a set of policies that should be governing access to some resources. So by trying to fix one semantic issue, you're introducing a bunch of other ones.

chefandy 2y ago

Between dev and administration/ops work, I spent a couple of decades in the deep end of the tech pool. As we know, it's packed with layers of interconnected archaic, arbitrary and confusing terminology. I understand the resistance to renaming things – the cognitive overhead of learning new terms is real. However, when you remove decades-irrelevant technical limitations and contrived entomological justification, the reason for sticking to old, confusing names often boils down to "because I already know it." Many feel learning it all has earned them this machismo-driven badge-of-nerd-honor, and people advocating for more straightforward terminology are often viewed as weak, lazy, or incompetent. That's convenient for us, but hindering future generations and confusing non-technical users has a cost. For a field so focused on progress, this resistance to improving terminology is strange. While I don't advocate for constant change, or change for its own sake, we should challenge "because, that's the way it's always been" as a justification for not making things better.

potus50 2y ago

Honestly, Im tired of people telling me how to talk. What if instead of policing language we educate people on the differences between authentication and authorization and best practices for implementation? I think you’re onto the problem, but artificial language enforcement isn’t going to fix it.

oaiey 2y ago

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

tracerbulletx 2y ago

[flagged]

deleted 2y ago

[deleted]

unixhero 2y ago

Instead of plural accesses we should say entitlements

mic_check_123 2y ago

Authentication is when the bouncer checks your drivers license. Authorization is when he lets you in the bar. AuthN can be achieved numerous ways that don’t even closely imply a “login”. The terms we have suffice, it’s the education around them that is sorely lacking.

thayne 2y ago

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

pseudocomposer 2y ago

I think it should be “authentication” and “permissions.” There’s pretty much no word in the English language to describe login/account creation/etc than “authentication.” The word “login” is a poor substitute. There are no good synonyms for “authentication” that encompass all its applications in computer systems. Meanwhile, there are already lots of synonyms used for “permissions.” Given the abundance of these, and the lack of synonyms for “authentication,” choosing “authorization” to describe permissions is, frankly, an asinine decision. It adds unnecessary cognitive overhead for everyone. (That’s not to say there’s no place for, say, Unauthorized responses, etc. Just that we should be calling the topic “permissions” or really anything other than “authorization.”)

brhsagain 2y ago

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

deleted 2y ago

[deleted]

libria 2y ago

We carry a physical analog of this in real life: work badge. My policy-enforced visible picture identifies who I am and that I match that photo and also gatekeeps me into and out of places I'm allowed to enter. > terminology implies that the two concepts, authentication and authorization, are more closely related than they are ... There are some links ... because what you can do is tied to who you are. But they're also very different AuthZ being entirely dependent on AuthN is not "some links". That's an unbreakable dependency. I can agree that these two words being a single letter apart are easy to conflate though. But as they are related, we're more likely to increase training/education around the concept rather than rename them.

slackfan 2y ago

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

ngc6677 2y ago

What about using `sign`? - sign-up - sign-in - sign-out Example https://radio4000.com/sign https://radio4000.com/sign

hnbad 2y ago
This doesn't address auth(orization), i.e. "permissions", and it also introduces worse usability for non-native speakers. "Sign in" and "sign up" are hard to distinguish for some demographics (especially non-native speakers) so putting them side by side like that while creating nice symmetry makes it harder to understand. I think some research by Nielsen twenty-ish years ago suggested using "Sign in"/"Sign out" and "Register". It feels like "Log in"/"Log out" won out on most of the web (e.g. Facebook uses "Log in"/"Log out" and "Sign up").

NovemberWhiskey 2y ago

So, uh, when my browser checks that the certificate for a site has a DNS SAN that matches the name I used to access it, is the website "logging in" my browser? And does a signed S/MIME email "log in" to the MUA that receives it? Authenticate is a perfect good word, let's keep using that.

dagss 2y ago

Don't say auth, say authn and authz.

MattPalmer1086 2y ago

I sympathise with the author wanting to make the meaning of these more obvious, but login is not a good synonym for authentication. Login implies the process of obtaining a session by providing some credentials; this is not the same as authenticating, which can be achieved without requiring a session (e.g. bearer token). I do quite like permissions for authorisation though.

deleted 2y ago

[deleted]

valenterry 2y ago

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

debuggerpk 2y ago

authn, authz for me.

BrandoElFollito 2y ago

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

tripa 2y ago

I'm fine with permissions. Heck, it's what I already say. Login, no, just no. Login is ambiguous to begin with, is it the action or the user identifier? Login as the process of logging in, the best interpretation, is still pretty limited: authentication is the validation of a much longer chain of events than that. It may start with login, but it lasts for as long as the service accepts to believe such principal is behind such actions. Login as username is IMHO the most common use of the word, and most obviously the wrong one to mean authentication. To make things me interesting, auth already means authentication to me. I accept it can lead to confusion and a better substitute would be welcome.

dinkumthinkum 2y ago

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

throwaway984393 2y ago

[dead]

bytearray 2y ago

Everyone should use the terminology I prefer.

dboreham 2y ago

No.

_factor 2y ago

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

bitwize 2y ago

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

3np 2y ago

"login" makes the situation of conflating authentication and authorization worse, not better. "Logging in" can mean either authentication, authentication+authorization, or authorization depending on context. Specifically, "logging in" does not need to imply authentication. Example: I "log in" to a public WiFi hotspot using a shared password written on the wall. Yet, there is no authentication taking place.

nikolay 2y ago

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

balex 2y ago

"Most computer systems we interact with have an auth system of some kind." The first sentence in the article actually highlights a nice "side effect" of the very thing it complains about. Covering "Authentication" and "Authorization" with a single "auth". Convenient for those who understand the concepts and don't need the distinction. Especially since these terms are strongly related and often come together.

sixdimensional 2y ago

In traditional security training, you learn the "AAAs" of security - authentication, authorization and accounting (and don't forget the last one!). It's good to have ways to easily capture the meaning of these words, but permissions and login are implementations that fulfill the requirement of the As, not the As themselves.

Justsignedup 2y ago

Honestly, I never allow people to abbreviate. You have to say "authenticate" (who are you) vs "authorize" (what are you allowed to do). In fact I flag most abbreviations in code, for exactly this reason. We aren't charged by the character, spell it out, future you will always thank you.

cryptonector 2y ago

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

HeavyStorm 2y ago

Yeah, no.