[HN Gopher] Instead of "auth", we should say "permissions" and "...
___________________________________________________________________
Instead of "auth", we should say "permissions" and "login"
Author : tambourine_man
Score : 408 points
Date : 2024-05-27 15:11 UTC (7 hours ago)
(HTM) web link (ntietz.com)
(TXT) w3m dump (ntietz.com)
| verdverm wrote:
| "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 wrote:
| The other term you might here is AAA: Authentication,
| Authorisation, and Accounting
| verdverm wrote:
| by Accounting, do you mean Audit Logs?
| candiddevmike wrote:
| 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 wrote:
| I can see this thread rabbit-holing into logmon
| terminology :]
| spicybbq wrote:
| > I personally like saying authnz (authentication and
| authorization mashed together)
|
| a12n and a11n, if you will.
| verdverm wrote:
| which ideally are a11y (accessibility)
| jameshart wrote:
| Yes, this. Access control is bigger than just permissions. And
| identity is still relevant even for anonymous users.
| bsid wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| chipdart wrote:
| > "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "Identity" and "Access" are really good names.
|
| I could easily adopt those if I find myself naming middleware
| again.
| greggyb wrote:
| 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 wrote:
| 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 wrote:
| Or use the industry standard AuthN, AuthZ nomenclature?
| jedberg wrote:
| 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 wrote:
| 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 wrote:
| >> They aren't universal enough
|
| Yes, we need a NEW standard: https://xkcd.com/927/
| jedberg wrote:
| 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 wrote:
| 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 wrote:
| > there are no verb forms
|
| Authenticate. Authorize.
| alephxyz wrote:
| Authentify is also valid but obviously leads to even more
| confusion
| kazinator wrote:
| Never heard of it.
|
| Just don't use the "auth" contraction for "autorization". Only
| for authentication. Or not at all.
|
| The system state which grants access to a resource based on a
| user's credentials is "permissions".
|
| Authentication is the process of establishing belief in the
| user's credentials.
|
| Authorization is the human assigned permission to a resource
| which may or may not be reflected by permissions. Incorrectly
| set permissions can allow unauthorized access to a resource.
|
| E.g. if /etc/shadow is accidentally made rw-r--r--, that
| doesn't mean everyone is authorized to access the password
| hashes. Doing so may still violate the organization's IT
| policy.
| zdw wrote:
| 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 wrote:
| The article is specifically arguing against using "auth" or
| "authn/authz"
| PKop wrote:
| "Most places say AuthN and AuthZ" is what the post is arguing
| against.
| 1970-01-01 wrote:
| 90% of development and IT is knowing acronyms and abbreviations.
| The other half is skills.
| hsdropout wrote:
| And the other 50% is concentrated power of will.
| nailer wrote:
| > 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 wrote:
| 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 wrote:
| Ah yes, the good old "the jargon for X is confusing, let's add
| more jargon".
| bazil376 wrote:
| 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 wrote:
| Especially when English is not your first language. These words
| are long and easy to mix up
| rockemsockem wrote:
| I can empathize with this struggle, but I don't think that
| warrants changing terminology.
| lelanthran wrote:
| > 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 wrote:
| Authorization code? Do you mean authentication?
| danielmarkbruce wrote:
| No, they probably don't. They probably know exactly what
| they are saying.
| lelanthran wrote:
| I don't mean authentication. An authorization code is
| something that is handed out to already authenticated
| identities.
| cpdean wrote:
| But how else will I signal my superiority over others if I use
| clear language???
| bazil376 wrote:
| ;)
| ziddoap wrote:
| > _login and permission._
|
| These words do not capture everything that authorization and
| authentication entail. As stated several times in this thread,
| permissions are specific part of what authorization entails,
| not the entirety.
|
| > _Sometimes I feel like we enjoy fancy terms more than we
| enjoy unambiguous terms_
|
| Authorization and authentication _are_ unambiguous.
| DowagerDave wrote:
| 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 wrote:
| 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 wrote:
| Fun parallel: 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 wrote:
| > 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 wrote:
| For some reason, with both words, I have to stop and think
| about what the "other auth- word" is so I can be sure I'm
| thinking of this "auth word" correctly. 1. Sees
| <authentication> 1a. "That's who I am, but to be sure..."
| 2. "Ehh... the other one is... <authorization>..." 3.
| "<authorization> is what I'm allowed to do so..." 4.
| "...yes, this one is who i am"
|
| Seriously, every time. I probably worried I'd remembered it
| backwards at one point early in my career and have never shaken
| the habit of double-checking myself on it.
| codelikeawolf wrote:
| I did the exact same thing when I was reading the post! I had
| to stop reading and take a good 10 seconds to verify which
| one was which in my head. I use "auth" all the time as a
| placeholder for "you need to login to use this". I've never
| really thought too much about authorization versus
| authentication because to me, those are just implementation
| details under the "auth" umbrella.
| pama wrote:
| I authorize you to be authentic!
| test6554 wrote:
| Hey, I wish electrons were assigned a positive charge and
| protons a negative one. Way back when. But oh well now.
| echoangle wrote:
| Can you explain why switching the names would be better? I
| don't get it
| cocoa19 wrote:
| I remember some messy conventions in electronics as a
| reason.
|
| The conventional flow of current goes from positive
| terminal to negative. But electrons actually flow from
| negative terminal to positive.
| thaumasiotes wrote:
| By convention, electrical current flows in the direction of
| the movement of positive charge.
|
| However, in the typical case, what's moving is electrons,
| which means the "current" is flowing in the opposite
| direction of the movement of the electrons. This is stupid
| and everyone hates it.
| djaro wrote:
| Because what we call electricity is electrons moving. So it
| would make sense for electrons to have the electric charge.
|
| Now we are in a weird situation where current flows from
| positive to negative, but electrons flow from negative to
| positive. It would be a lot more logical if the direction
| of the electrons was the direction of the current, but the
| name was arbitrarily decided before we knew what electrons
| were.
| samatman wrote:
| In addition to the sibling comments, I have a somewhat
| esoteric reason to wish that the signs of electric charge
| were reversed.
|
| In the coordinate system of an atom, the nucleus is at the
| origin, 0, while the electrons are a positive distance from
| that core. 0 is not negative, obviously, but it's non-
| positive.
|
| When terminology is concordant in this way, the topic is
| easier for a student to grasp. When discordant, harder.
|
| There's little chance for this wart to be remedied,
| invalidating every paper written up to that point is a bit
| of a non-starter. But I dislike it nonetheless.
| abecedarius wrote:
| Also when you're learning organic chemistry, where you
| need to mentally push electrons around molecules which
| are diagrammed in a highly compressed notation, the
| negative charges add just a bit more to your working-
| memory load (which might've already been on edge of what
| you can handle without dropping something) until you've
| had enough practice to compile the patterns down.
|
| Negating when you move electrons is just one more step,
| but so is negation within a complex expression in
| language or programming, and we do try to avoid piling
| that up.
| thayne wrote:
| Because in an electrical current it is electrons that move
| (usually, unless you have a hydrogen plasma or something),
| so since electrons have a negative charge, the direction of
| the positive current is the _opposite_ of the direction the
| electrons are flowing.
| randomdata wrote:
| _> and protons a negative one._
|
| A "pro" negative? That introduces a whole new confusion.
| ape4 wrote:
| Since nobody else has mentioned it... the Apache authn and
| authz modules
|
| https://httpd.apache.org/docs/2.4/mod/mod_authn_core.html
|
| https://httpd.apache.org/docs/2.4/mod/mod_authz_core.html
| dathinab wrote:
| > or we could just use the longer words?
|
| we could but don't expect anyone with dyslexia noticing that a
| text says authorization when they subconsciously expect
| authentication (and don't explicitly double check)
|
| Through also if we use AuthN and AuthZ (with capitalization)
| it's quite clearly readable and hard to mistype and no longer
| the kind of words dyslexia makes it easy to misread (it never
| was in the category of things dyslexia makes easy to
| accidentally mix up when writing I think).
|
| Using authorization and authentication also can have issues if
| you use a text editor with auto completion, for AuthN/AuthZ you
| simply could not use autocompletion.
|
| > My guess is they ran into something like installing a package
| that didn't cover their desired needs,
|
| or got into problems because they used the wrong term in
| technical documentation, maybe in context of a security review
| or a requirements document which has been legally binding
| singed of
|
| > The confusion is not going to be solved with trying to
| relabel the concepts.
|
| Especially given that login likely implies both AuthN and AuthZ
| so it's not even "just" relabeling.
| karmakaze wrote:
| I actually like AuthN and AuthZ as they serve as keywords
| rather than easy to misinterpret natural language.
| xyst wrote:
| "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 wrote:
| I've never been in a situation where this "confusion" happens
| (nor in english or spanish, where we use autenticacion and
| autorizacion), 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 wrote:
| Agreed. Generally just avoid jargon when you aren't sure the
| reader knows the lingo.
| Pxtl wrote:
| Because people frequently in English use the abbreviation
| "auth", which is ambiguous.
| ziddoap wrote:
| 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 wrote:
| 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 wrote:
| > _The suggestion here is to use one common and correct
| phrase instead of another common and correct phase_
|
| Permissions are a subset of authorization.
| hu3 wrote:
| Could you please provide examples.
|
| I see comments stating that, but no examples.
| ziddoap wrote:
| Permissions are a technical method which are used to
| implement and enforce authorization policies. However,
| authorization policies are not composed of just
| permission controls.
|
| You may find that your user account has _permission_ to
| read the employee salary database. However, you may not
| be _authorized_ to read that database by corporate policy
| because you are not a manager. Perusing that database
| will still get you in trouble, because you aren 't
| authorized to do so, even though your account had the
| technical permissions to access it.
|
| You may find that you have permissions to screenshot
| internal databases and post them on facebook, however
| since you are not authorized to do so by policy, you will
| be fired.
|
| Etc.
| hyperpape wrote:
| > You may find that your user account has permission to
| read the employee salary database. However, you may not
| be authorized to read that database by corporate policy
| because you are not a manager.
|
| It's true that there are technical enforcement
| mechanisms, and corporate policies, but it is false that
| the former must be called permissions, and the latter
| must be called authorizations. The policies can easily be
| called either authorization or permission. It is true
| that we refer to e.g. Unix file permissions, and a
| corporate policy is more likely to use "authorization"
| but this is not a semantic difference--the corporate
| policy would be correct and binding if it used the word
| permission.
|
| If a fellow employee asks you "do I have permission to do
| this?" you must say "no" (or alternately "you're not
| permitted, even though the computer will not enforce
| that"). Saying "yes" because there is a technical
| permission would be a very bad idea.
| ziddoap wrote:
| You are correct that it is not a _law_. If you, in a
| conversation, were to say "permission" in place of
| "authorization", you'll broadly be understood.
|
| However, for as long as I've been in the business, those
| terms refer to different things. That is how it is taught
| in school, how it is referred to in documentation, how
| you have to understand them when you write your CISSP,
| how various governing bodies separate and refer to the
| ideas, etc.
|
| During an audit, if you are asked for your authorization
| policy and you give them a list of file permissions, you
| are failing your audit (well, not really, but you'll
| probably get a scoff and a condescending clarification of
| what the auditor wants -- and it is never good when an
| auditor becomes condescending).
|
| In a professional context, permissions are a specific
| technical enforcement of an authorization policy.
| danielmarkbruce wrote:
| You have read permission on a file - generally used by
| humans, and UIs like on Google Drive etc to signify your
| ability to see a file at all, at some time, some
| location, from some machine.
|
| You have authorization - you are allowed to see the file
| now, from this machine attached to this network in this
| geographic location using this type of authentication.
|
| "I have permission to see this file, but I can't access
| it outside the corporate network" said many people lots
| of times.
| zogrodea wrote:
| The last example just points to two types of permissions
| coming from different sources.
|
| "Leadership gave me permission to view this file, but the
| computer/network doesn't permit me to do that."
| danielmarkbruce wrote:
| Yep, you could change the currently used meaning of
| permission to mean two different things, usually granted
| by two different processes. And you'd have confusion.
|
| No matter what you do here, there isn't a simple
| solution. It's complex.
| AbraKdabra wrote:
| So the problem is the people not the words.
| mkroman wrote:
| "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 wrote:
| 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 wrote:
| Indeed, Authorization includes things like license checks, time
| of use restrictions, etc.
| hu3 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| badgersnake wrote:
| 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 wrote:
| 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 wrote:
| >> 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 wrote:
| 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.
| sergioisidoro wrote:
| 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
|
| [2] https://www.merriam-webster.com/dictionary/unauthorized
| yashap wrote:
| 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 wrote:
| 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.
| Perz1val wrote:
| - 403: I have it, but you should seek the admin to give you the
| right permission - 404: I don't even have that (lying)
| onionisafruit wrote:
| Also in the http world, the header used for authentication is
| called "Authorization"
| bongodongobob wrote:
| 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 wrote:
| '"Auth" can mean at least two things: authentication or
| authorization' - the two words you should be using.
| jmsgwd wrote:
| 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 wrote:
| 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
|
| 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.
| progx wrote:
| So we are back to the most difficult things in programming:
| naming things.
| ratiolat wrote:
| Agree with the article. The worst offender is probably Oauth
| providing endless confusion to developers and end users
| jmull wrote:
| 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 wrote:
| The solution to authentication and authorization being hard to
| keep straight is to keep using authentication and
| authorization?
|
| How is that a solution?
| baronvonsp wrote:
| 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 wrote:
| ...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 wrote:
| 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 wrote:
| > 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 wrote:
| And script, instead of "app".
| aeonik wrote:
| "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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| dergyitheron wrote:
| It's not that simple for non-native English speakers, not
| everyone works in an international team so English is being
| used on a technical level and you basically have to memorize
| what those words mean if they dont have similar sounding
| equivalent in your native language. And there people mess it up
| or simplify the terms by combining them and it doesn't make
| sense. And you wouldn't use your native language equivalents
| because docs are usually in English and we code naming things
| in English. Using those dumber terms would be much more
| straightforward for everyone.
| marcosdumay wrote:
| > non-native English speakers
|
| Hum... I imagine you mean people without any Latine
| inheritance in their culture. Those words are very good words
| on way more languages than English.
|
| Those words are also shared with other domains, where they
| have compatible meanings, and that intersect the usage in
| computer systems. So you'd better fix them there too.
|
| Besides "permission" is not a verb, and "login" is one
| between a lot of different ways to authenticate people. What
| do you intend to do with the correct meaning of those words
| once you overload them?
| hackernewds wrote:
| Auth means authentication or authorization? that's the dilemma
| alex_lav wrote:
| Sure, so why would we replace the two words that have correct
| meaning when the real problem is laziness?
| croes wrote:
| We now have autocomplete that could choose the wrong word.
| alex_lav wrote:
| We've had autocomplete that could choose the wrong word
| for over a decade. And?
| theptip wrote:
| The industry has used "authz" and "authn" to disambiguate for
| decades.
| cdelsolar wrote:
| I've been working in this industry for decades and this is
| the first time I made that connection...
| mgkimsal wrote:
| you're not alone.
| bostik wrote:
| The distinction was already present in Apache2 configs in
| early 2000's, although there _authentication_ was
| "auth", and "authorisation" was _authz_.
|
| Real travesty came from OAuth. A system designed to
| handle authorisation was named after the term for
| authentication.
| recursive wrote:
| But then it mostly ended up getting used for
| authentication anyway, so maybe it was ok.
| foobazgt wrote:
| I can second GP.
|
| I have always heard and used authz and authn (pronounced
| auth-z and auth-n). Bare "auth" typically was used to
| mean both, but IAM was more clear for that in specific
| contexts. E.G. you might say someone "authed" to indicate
| both authentication and authorization, and you might have
| an IAM team that handles both authentication and
| authorization.
|
| FWIW, I lead an IAM team.
| croes wrote:
| One type and you have a problem.
|
| Maybe it's better to use less similar words if it's
| security related.
| mgkimsal wrote:
| How are those pronounced?
| giaour wrote:
| You pronounce the last letter as a second syllable: authn
| is "auth-in" and authz is "auth-zee" (probably "auth-zed"
| in non-American English).
| erik_seaberg wrote:
| I've seen
| https://en.wikipedia.org/wiki/AAA_(computer_security)
| because authentication, authorization, and accounting
| (audit trails) need to go together so often. You need to
| know who they really are and whether they're abusing the
| system.
| selecsosi wrote:
| AuthN and AuthZ are appropriate and succinct ways to express
| the concerns when brevity is required
| croes wrote:
| So one wrong letter or wrong auto complete and we have the
| wrong meaning.
|
| In security, anything that is less prone to error is good,
| so words that are hard to confuse or misspell are good.
| selecsosi wrote:
| Why would you type the wrong letter when you mean the
| other one? Authentication means proving what something
| says it is, authorization is allowing someone to do
| something.
|
| The concepts are different so it's not like a dial you
| are turning to make a measurement, the terms are for
| different domains
| deathanatos wrote:
| While I also agree that authn or authz are perfectly
| clear,
|
| > _Why would you type the wrong letter when you mean the
| other one?_
|
| Really? Ignorance, laziness, rushing, fatigue, simple
| mistakes, etc.
|
| What I think is worse is more letters doesn't save you.
| I've had some conversations where it has gone like 2-3
| round trips before the other end realizes that "not"
| means not, and they mean ... the other way.
| dathinab wrote:
| yes but it's also even more important to be precise and
| correct which login/permission fail to be
|
| login is at best defined as authorization +
| authentication
|
| but things which are in general referred to as login but
| only provide authorization are not that rare (e.g. you
| pass a token to a client)
|
| and logins which to provide authentication but not
| authorization exist to (but are rare and you probably
| could always nitpick them out of existence)
|
| Similar the term permission is hugely overloaded due to
| it's wide usage in more causal most times end user facing
| documentation. Most times permissions are used in a more
| generic context, like a user having the permission to do
| something vs. a request made by a user being authorized
| to do something.
|
| I mean in the end there is no reason not to use
| login/permission for end-user facing documentations,
| causal conversations etc. This terms are "good enough"
| most times. But if you provide a login library or
| technical documentation for APIs with complex
| interactions between authentication and authorization
| then using login/permission just won't cut it.
|
| Also for AuthN,AuthZ there is no point to use auto
| completion and there is very very little chance to
| mistype them as long as you don't confused them. Luckily
| this kind of mistakes do not fall under the patterns
| dyslexia causes (especially if you do the
| capitalization).
| baronvonsp wrote:
| These are widely-used industry terms that have been used
| for decades. If that was a problem, surely we would have
| seen it by now?
|
| Replacing terms - that have been around so long that many
| systems' behaviors map to them closely - with new terms
| that don't quite overlap seems wildly more likely to
| create ambiguity and confusion.
| Jach wrote:
| No, it is not the case that anything that is less prone
| to error is good.
| croes wrote:
| Strange take on errors.
|
| Less error prone means less errors means better results.
| Better results are good.
| Jach wrote:
| Getting fewer errors does not mean better results --
| sorry, I don't really want to continue this conversation
| of answering vastly general assertions backed by nothing
| with counter-assertions backed by nothing. My bad, since
| I started this way. The real objection I have that takes
| longer to articulate is that this logic is way too
| simplistic, broad, and worthless.
|
| I'll try to articulate a bit though, but it probably
| needs expanding into more than a comment to have a chance
| at persuasion. When you start trying to derive logic
| chains that conclude in good, leading you to further
| conclude other things are bad, and base your decision
| making on what's good/bad in these chains, you've made a
| mistake. Engineering should be focused on trade-offs, not
| some binary and local good/bad. Engineering should be
| focused on measurements, not platonic qualities like
| "good". The world isn't so coarsely binary. So what if
| your results are better? Are they accomplishing something
| good down the line, like being better at [insert
| something you find morally objectionable]? And given we
| have limited resources, is the amount something is better
| worth expending the effort on it vs. something else, or
| even worth it relative to a measured good-enough steady
| state? Does the local change meaningfully impact the
| overall system at all? (You may be familiar with a semi-
| famous (around HN) article "The optimal amount of fraud
| is non-zero", if not, I recommend it.) Lastly, you need
| to actually look at what kind of errors there are, how
| they surface, _when_ they surface (e.g. during software
| development, during design and prior to any code, during
| a test phase, or discovered by the end user), and their
| consequences for surfacing. You need to analyze whether
| something is actually less error prone or is just good at
| hiding its errors and continuing on. You need to look at
| whether the errors are loud or subtle.
|
| All this high level chatter is of course further
| pointless in this specific concrete context. As someone
| already pointed out, it's exceedingly unlikely for a
| developer to confuse authN and authZ in practice for any
| significant duration. You can't just import and write
| code for authN when you meant authZ and expect things to
| "work" while perhaps errors accumulate (silently or not),
| because these terms express different concepts, different
| protocols, and different APIs. The code will simply not
| work, immediately. In a sense, this makes it quite error-
| prone if you typo what module you're importing to do your
| authN/authZ work. This isn't necessarily a bad thing
| because you'll see the error and fix it before it ever
| has a chance of impacting anything important. Would it
| have been better to not make the typo to begin with?
| Sure, but not meaningfully so. Focus on more important
| problems.
|
| Meanwhile, to take a different concrete case, if you're
| writing crypto code and accidentally use ECB block cipher
| mode vs. CBC (a reasonable typo to be concerned about,
| even), _everything will continue to appear to work_. But
| you 're already FUBAR. Of course, there are many subtle
| such errors in cryptography, and you can even choose the
| right cipher mode and still make huge mistakes that
| aren't immediately obvious, and not because of some
| trivial typo either. (Another semi-famous article you
| might want to check out, if you haven't, is "If You're
| Typing The Letters A-E-S Into Your Code, You're Doing It
| Wrong".) It's interesting to consider that the industry's
| broadest recommendation in the face of how error-prone
| implementing crypto code can be is to say "Don't" rather
| than to try and somehow make it less error-prone.
| spacebanana7 wrote:
| AuthZ is troublesome in British English domains where the
| usual spelling is Authorisation.
| calrain wrote:
| 100%, this is a standard approach.
|
| If you're new to this concept, then you're new to
| programming in this space.
| bradjohnson wrote:
| Identity and permission are often closely related, and
| usually auth means both. If we replaced auth with permissions
| and login, I suspect we would still encapsulate the same
| overarching concept with one of those two words anyway. E.g.
| use the login module to add permissions to a user or use the
| permissions module to authenticate.
| ghnws wrote:
| Having two almost identical terms that mean completely
| different things is not a very good idea. Also here you are
| explaining what the words mean, when "login" and "permission"
| are immediately obvious. Most people don't speak english
| natively either.
| 4death4 wrote:
| I don't really consider making an API call as "logging in".
| The term sounds really out of place other than in a few
| specific contexts.
| rwoerz wrote:
| Indeed. "Logging in" implies some kind of long lasting
| session. And logging in conceptually only requires
| "identification" (e.g. via a username) but not necessarily
| "authentication" (e.g. via a password)
| nmz wrote:
| Identification is not necessarily via a username, people
| can identify you via just knowing how you look or your
| voice, the method doesn't matter.
| Too wrote:
| The term "Identify" is a lot better in this regard.
|
| It's already universally used in IAM, where the other half
| of the puzzle is also clear and free from ambiguity:
| "Access".
| jbverschoor wrote:
| Access doesn't cover everything though. But identify
| seems good
| jonplackett wrote:
| I think they mean use both - identity in place of
| login/authenticate and access in place of auth
| jbverschoor wrote:
| Yeah, but access to me feels like access to records. Not
| necessarily permissions to do certain actions (in general
| or to certain records)
|
| Iirc, Java or J2EE used "Principal", which I found super
| confusing
| adolph wrote:
| And the third half, "management" verbalizes the action
| therein.
|
| Also, IAM has a cryptic assertion of ultimate authority:
| _In Hebrew, . . . hayah carries the added weight of
| representing God himself: Yahweh, "I am."_ [0]
|
| https://hebraicthought.org/meaning-of-gods-name-i-am-
| exodus/
| zer00eyz wrote:
| Identity/identify may or may not have anything to do with
| Login, or Authentication...
|
| KYC (know your customer) are about removing the ambiguity
| between you user and their identity....
| recursive wrote:
| What could be a difference between identification and
| authentication? In my understanding they are completely
| synonymous. I frequently use an IdP (identity provider)
| to authenticate for web applications.
| duncan-donuts wrote:
| I think authentication is about proof of identity.
| Identity can mean a lot of things imo. Applications
| identify me all the time without me giving them any proof
| of who I am. This happens in meatspace all the time too.
| People project identity and we make assumptions about
| what we observe. We don't necessarily ask them to verify
| this identify through mutually agreed upon terms.
| zer00eyz wrote:
| Know your customer is something that started in banking
| and is leaking everywhere.
|
| Identity is who you really are. Be that you as an
| individual or as a corporation.... In the case of your
| bank they have a copy of your ID, your SSN, for them
| identity is what established the account and auth lets
| you work with it.... AWS might know some members of your
| company (either by corporate or individual card) but
| might not know your identity (as an individual) and yet
| you can still authenticate, because you have been
| authorized by an identified customer. I can transact with
| crypto as an authenticated user and NOT be identified.
| asalahli wrote:
| Identification and authentication are different, though.
| You identify yourself to a website as a specific user
| (e.g. using a username) and the website in turn
| authenticates your claim, i.e. verifies that you are in
| fact the user you claim to be (e.g. using that user's
| password).
| amne wrote:
| If you go that route .. your OIDC provider authenticates
| your claim. The website just trusts some specific OIDC
| authorities which you must use to create your identity.
| jagged-chisel wrote:
| IMO...
|
| To "log in" is to convert the username/password pair (or
| API key, or whatever) into a smaller token with an
| expiration. Doesn't matter of it's put in a cookie in my
| browser, held in memory by some other API client, etc.
|
| Aside: Why bother even doing that? Because every time you
| transmit the credential, there's the possibility of
| leaking. We would rather leak the token that has an
| expiration.
| mepiethree wrote:
| I don't think they are almost identical, they just have the
| same prefix. "Login" and "permission" each have the same
| problem: "login" is very similar to "logging", and
| "permission" shares a prefix with "persistence" (or
| permanent). Ultimately software engineering is a broad enough
| field that we will necessarily have to use similar words to
| describe the many, many concepts
| croes wrote:
| But authentication and authorization are often used in the
| same context where confusion is lethal.
| coldtea wrote:
| Why would it be "lethal"?
|
| As a dev you're either building or hooking up to either
| or both of them. And you know what each requires you to
| build / hook up to.
|
| As a user, you just care "I put my login/password/api key
| here, and I get the capability to do several things in
| that webpage/service/etc". Both auth and the other auth
| are handed for you.
| croes wrote:
| Ever heard of a hyperbole?
|
| And if the other dev made an error and confused
| authorization and authentication you have a problem.
|
| Stupider mistakes have been made and it is a sign of
| overconfidence if you think you are immune to them.
| pjerem wrote:
| The issue is that they have the same prefix AND that
| unfortunately this prefix is used to abbreviate both words.
|
| What does the "auth" module ?
| diego_sandoval wrote:
| We shouldn't use that abbreviation, then.
| bigyikes wrote:
| Not a good analogy.
|
| "Permission" and "persistence" have the same prefix but
| entirely different semantics. They also occur more commonly
| in everyday life.
|
| AuthN and AuthZ are similar in in spelling, appear in
| similar contexts, and are less colloquial, making the
| distinction a lot less clear.
|
| There's a reason many junior devs use them interchangeably
| without knowing better.
| gtirloni wrote:
| what's the difference between login and logon?
| bru wrote:
| That's because they share the same root auto-, i.e. "self".
| Because they're related concepts...
| mistercow wrote:
| The wild thing is that they're apparently from different
| etymologies. "Authorization" comes from "auctor" in Latin,
| meaning "leader" or "author", whereas "authentication"
| originally comes from the Greek "auto" meaning "self". There
| probably was some cross influence that brought them into line
| though.
| rockemsockem wrote:
| You're saying that they are almost identical because they
| share the first 4 letters.... That's a pretty low bar.
| inopinatus wrote:
| "login" refers to the record of access1, not the access
| itself, so it is more properly associated with audit. This
| dates from the early days2 of time-sharing systems when you
| didn't need a password, you were just saying hi to the
| computer.
|
| __________
|
| [1] Derived from the signing of a ship's logbook3 when coming
| aboard.
|
| [2] A few decades ago.
|
| [3] The logbook originally4 recorded navigational data and is
| named for instruments measuring speed through water5, of
| which the simplest is literally throwing roped wooden logs
| off the stern and counting the knots on the line paying out
| per interval6.
|
| [4] Doubtless some bright-eyed young hornblower with a
| glittering future career as an admiralty archivist realised
| that log-structured records could be generalised usefully to
| all timestamped event and measurement capture, which is why
| your syslog is full of crap.
|
| [5] Consequently any vessel, maritime or otherwise, measures
| its speed through the medium in knots. The Enterprise
| NCC-1701-D, for example, tops out ca.146 megaknots under
| impulse engine.
|
| [6] It follows by transitive etymology that you may use the
| term "knots" to edify and delight your colleagues when
| referring to the rate of creation of user sessions.
| joemi wrote:
| offtopic, but: I think when your footnotes themselves need
| footnotes, there's probably a clearer way to write what you
| wanted to write. Jumping through multiple levels of nested
| footnotes is fairly hard to read, at least for me.
| inopinatus wrote:
| Indeed; they are log-structured.
| mrgoldenbrown wrote:
| It's most likely not that they needed footnoted
| footnotes, rather that they wanted them and structured
| their post on purpose to create them.
| jknoepfler wrote:
| I disagree. To authenticate something is to challenge it to
| prove its identity. Authentication is much broader in scope
| than "login," even within the narrow domain of computer
| science. JWT signing, domain certs and so forth fall under
| the "authN" header and use the same cryptographic tools and
| techniques... even many forms of user authN don't have a
| "login" flow.
|
| Why would we choose "login" - which is more of a special case
| than the norm to describe something we already have a precise
| term for?
| popalchemist wrote:
| Most people literally do speak English
|
| https://www.google.com/search?q=most+popular+language+in+the.
| ..
|
| but the rest of your point is dead on.
| amrangaye wrote:
| Sorry I don't understand - the link you posted shows that
| "most people" actually speak mandarin and Spanish?
| nulbyte wrote:
| If you think two different words having different meanings is
| difficult, wait 'til you hear about contranyms! English is
| full of words like these, where context is needed to
| understand the meaning.
|
| If something is fast, it moves quickly or not at all.
| Cocktails can be garnished, but so can wages. Sales or trade
| of a product could be sanctioned by one country, but
| sanctioned by another.
|
| I generally think it is a good thing to communicate clearly.
| Sometimes that means using words differently to explain
| something. Other times, that means using words the same way
| as others. I think this is a case of the latter.
|
| Also, I think the idea of "native speaker" is a bit of a red
| flag. There are plenty of people that speak English from
| birth but are utterly unintelligible, and there are plenty of
| people that speak English as a second language who speak more
| clearly than those.
| ysofunny wrote:
| over many years, I've noticed how it's all about differences
| that get more subtle and precise on every field. I think this
| specially after watching this the introduction of
| https://www.youtube.com/watch?v=OMaYFUm8kQQ
|
| this is specially complicated in fields with long histories.
| I've got an example that may only make sense in both english
| and spanish: fats, oils, gases/gasolines (grasas, aceites...
| gasolinas, petroleo)
|
| other subtelties fresh on my mind today:
|
| proposition vs axiom
|
| argument vs parameter
|
| (common) case law vs civil law
| jonplackett wrote:
| Think you're giving 'Everybody' a bit too much credit.
| divan wrote:
| > Everybody knows ...
|
| Especially non-native English speakers, right.
| redeeman wrote:
| well either they know the language to some functional degree,
| or they dont.
| vsuperpower2020 wrote:
| I can't imagine learning German or some similar language
| and complaining that their words aren't clear just because
| I don't speak German fluently enough.
| diego_sandoval wrote:
| The Spanish words are very similar to the English ones:
|
| - Autorizacion : Authorization
|
| - Autenticacion : Authentication
|
| - Autoridad : Authority
|
| - Autentico : Authentic
|
| I would guess that in other romance languages, they are also
| similar to the English version.
|
| "Log In", on the other hand, only makes sense in English. If
| you tell someone "Estoy registrando adentro" they will be
| dumbfounded.
| Muromec wrote:
| Language families other than romance and germanic exist.
| cwilby wrote:
| Saw the headline, found your comment within two seconds,
| exhaled with relief.
|
| Every time a cohesive pair of words is redefined, a new JS
| framework is born.
| OJFord wrote:
| Yeah me too, but then I actually read the (very short)
| article, which immediately addresses that and not much else.
|
| Better title would be 'instead of authz & authn ...' to make
| that clear, because it does just sound like they haven't
| heard of the concept at first.
| bsder wrote:
| > inherently intertwined, confusing, and subtle.
|
| Our _current implementations_ are like this. I 'm not convinced
| this is inherent complexity, though.
|
| It seems like almost all the complexity stems from people
| trying to create hooks to monetize all the pieces of the
| process.
|
| Security and usability feel like a second and distant third in
| importance.
| blablabla123 wrote:
| Yeah but it's hard to understand unless doing a lot with auth.
| Indeed "don't roll you own crypto" but you don't need a PhD in
| Mathematics to roll you own auth. Sometimes it's necessary and
| even if not, it's good to know what could need work.
| bossyTeacher wrote:
| Old isn't always better.
|
| Also, I love how you say that everybody knows the meaning of
| those words yet you feel compelled to provide the meaning.
| Doesn't really make a good case in your favour.
|
| I highly doubt laymen would understand the difference when
| using "authorize" and "authenticate" as opposed to "permission"
| and "login". I would bet you $100 in bitcoin that most people
| would understand the latter.
| schrodinger wrote:
| I agree and was going to say the same thing, so instead I'll
| elaborate on another angle. (Also--don't shorten to auth solves
| the vast majority of this debate.)
|
| Some things in computer science are just plain "hard," and no
| amount of renaming or abstracting is going to solve it; you
| either need to take the time to understand it (i.e. learn
| authenticate = prove you who are, authorize = what are you
| allowed to do), or outsource the prob (e.g. "don't roll your
| own crypto").
|
| Similar problems:
|
| - Time. It's non-linear in calendar representations because of
| definition changes by humans. There are gaps in years trying to
| reconcile different calendars. There are leap seconds added
| based on scientific measurements, non-deterministic ways. Time
| zones enough confuse people. 99% of the time you can use
| something like "duration since 1970 UTC" (unix epoch) but you
| may eventually hit non-linearities if you try and say "once
| every 10 days" by doing 10 * secs / day.
|
| - Names. Different all over the world. I won't even give
| examples because I'm still a bit confused, I recently learned
| that in parts of India first name and surname are reversed, so
| not even consistent in one country. Prob best to just put a
| "Name" field and a "Nickname / Display Name" field and let the
| user decide.
|
| - Geodistance. The Earth is not a sphere, it's an "oblate
| ellipsoid" since the spinny makes the middle bulge. There are
| many ways to calculate distance between two coords and
| generally simple ones will work for majority of settlements.
| But if your customers are near the poles, or maybe include
| flight paths, etc the errors could be very significant. I've
| had this leak out in cases like Postgres where you can use the
| sphere approximation (much faster) or the proper calculationg
| (much slower) when running a query like "give me all points
| within a x mile radius".
|
| Auth (hah!) is just another one intrinsically difficult concept
| that's not made more complex by language and can't be
| simplified away.
| dataflow wrote:
| > 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.
|
| This sounds a lot like https://www.azquotes.com/quote/1026562
|
| Sorry, but you're just wrong here. The words are speed bumps at
| _best_ , and it would help a ton to use more instinctive words
| for them. Nobody needs to pause and think what login means, and
| that's not true for authentication.
| re wrote:
| They are excellent words but easily confused. See for example
| HTTP 1.0, which uses "unauthorized"/"authorization" to mean
| "credentials required"/"credentials", which persists in field
| names and status codes today.
| OvbiousError wrote:
| For me as a non-native English speaker, "authorize" and
| "authenticate" are always pretty unclear as to what exactly
| they mean in a security context. I don't use it enough for it
| to stick. I'll actually try to remember "login" and
| "permissions" as shorthand for getting a feel of what they are.
| And yes, I've never dug deep in security code/systems, but
| doesn't that make this even more of a problem instead of less.
| I should be able to understand what these concepts by
| themselves want to achieve without having a deep understanding
| of the technical details or coming into contact with it on a
| regular basis.
| oreilles wrote:
| Think of it in a real life context instead of a software
| context. Let's say you want to go inside a building and
| there's a bouncer at the entry. By presenting him your ID,
| he'll be able to authenticate you (determine who you are).
| Only then, will he decide to authorize you in, or not -
| depending of your right to do so.
| deanishe wrote:
| The problem here, I think, is the words, not the concepts.
|
| Like remembering when it's spelled "stationary" and when
| "stationery".
|
| "Still" and "paper" are easier to remember.
| barrkel wrote:
| The problem is the similarity of the words, not
| understanding the concepts.
| barrkel wrote:
| They're so unclear that HTTP error codes got them confused.
| 401 Unauthorized usually actually means Unauthenticated,
| while 403 Forbidden means Unauthorized.
|
| I'm a native speaker and I need to pause for a few hundred
| milliseconds just to be sure I'm using the right one in a
| sentence.
| pquerna wrote:
| What about "access controls" for the AuthZ side, instead of
| Permissions?
|
| Wondering HNs collective wisdom on this-- at work we've been
| using Access Controls on our homepage for awhile-
| https://www.conductorone.com/ - to the people outside the IAM-
| geek space does this make more sense?
| zzo38computer wrote:
| I think you are right, although sometimes other words may be
| better in some contexts. Also, "auth" can still be used if it
| is clear from the context or if you really mean both together,
| since sometimes they do go together and in that case "auth" can
| make sense. If it does not, then you can use full words such as
| "authorization", "authentication", etc.
| netfl0 wrote:
| No.
| layer8 wrote:
| "Login" implies a state change, which "authentication" doesn't.
|
| "Authorization" can refer to a process, which "permissions"
| doesn't.
| chaos_emergent wrote:
| Maybe instead of overloading the shorthand with two definitions,
| it's best to just use the actual words.
| steve_adams_86 wrote:
| 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 wrote:
| 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.
| WhitneyLand wrote:
| 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 wrote:
| 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.
| iandanforth wrote:
| Totally agree with this article and I'll try to use these words.
| spenceryonce wrote:
| Yes
| treflop wrote:
| Permissions to me is about setting a policy and authorization is
| applying that policy.
|
| I have never wanted to use them interchangeably.
| macspoofing wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I do not like it. AAAA is a good abbreviation for the necessary
| principles authentication, authorization, access and audit.
|
| LPAA... Is just not right.
| unixhero wrote:
| Instead of plural accesses we should say entitlements
| thayne wrote:
| > 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 wrote:
| 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 wrote:
| I've always heard "auth" to mean authentication and "perms" to
| mean authorization.
| libria wrote:
| 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 wrote:
| Nope. On general curmudgeon-y principle. Get off my lawn.
| ngc6677 wrote:
| What about using `sign`? - sign-up - sign-in - sign-out
|
| Example https://radio4000.com/sign
| hnbad wrote:
| 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 wrote:
| 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 wrote:
| Don't say auth, say authn and authz.
| MattPalmer1086 wrote:
| 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.
| valenterry wrote:
| 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 wrote:
| authn, authz for me.
| BrandoElFollito wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bytearray wrote:
| Everyone should use the terminology I prefer.
| dboreham wrote:
| No.
| _factor wrote:
| 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 wrote:
| What about auth9n and auth8n? a12n and a11n? To be compliant with
| the current belt onion for synthesizing obscure techie jargon.
| 3np wrote:
| "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.
___________________________________________________________________
(page generated 2024-05-27 23:00 UTC)