13 ms·

"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

• 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.
• deleted 2y ago
  [deleted]
• dergyitheron 2y ago
  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 2y ago
    > 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 2y ago
  Auth means authentication or authorization? that's the dilemma
  • alex_lav 2y ago
    Sure, so why would we replace the two words that have correct meaning when the real problem is laziness?
    • croes 2y ago
      We now have autocomplete that could choose the wrong word.
      • alex_lav 2y ago
        We've had autocomplete that could choose the wrong word for over a decade. And?
  • theptip 2y ago
    The industry has used “authz” and “authn” to disambiguate for decades.
    • cdelsolar 2y ago
      I’ve been working in this industry for decades and this is the first time I made that connection…
      • mgkimsal 2y ago
        you're not alone.
      • bostik 2y ago
        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.
• ghnws 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
        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 2y ago
      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 2y ago
        Access doesn’t cover everything though. But identify seems good
        • jonplackett 2y ago
          I think they mean use both - identity in place of login/authenticate and access in place of auth
• hwbunny 2y ago
  [dead]
• ysofunny 2y ago
  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 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 2y ago
  Think you’re giving ‘Everybody’ a bit too much credit.
• deleted 2y ago
  [deleted]
• divan 2y ago
  > Everybody knows ... Especially non-native English speakers, right.
  • redeeman 2y ago
    well either they know the language to some functional degree, or they dont.
    • vsuperpower2020 2y ago
      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.
    • divan 2y ago
      The point OP is making that those words are intuitive for readers (everyone). Knowing language is one thing, but intuitively making sense of similar words in a new context is another. Most non native English speakers think in their own language. Seeing word “authorization” simply doesn’t evoke the link with “authority” in their own language.
  • diego_sandoval 2y ago
    The Spanish words are very similar to the English ones: - Autorización : Authorization - Autenticación : Authentication - Autoridad : Authority - Auténtico : Authentic I would guess that in other romance languages, they are also similar to the English version. "Log In", on the other hand, only makes sense in English. If you tell someone "Estoy registrando adentro" they will be dumbfounded.
    • Muromec 2y ago
      Language families other than romance and germanic exist.
      • bigstrat2003 2y ago
        And programmers who work in those languages are more than welcome to use terms that make sense to them! There is zero reason to change terms that are perfectly clear to English speaking programmers simply because not everyone speaks English (or languages where English got its words from).
• cwilby 2y ago
  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.
  • deleted 2y ago
    [deleted]
  • OJFord 2y ago
    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 2y ago
  > 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 2y ago
  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 2y ago
  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 2y ago
  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 2y ago
  > 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 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 2y ago
  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 2y ago
  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 2y ago
    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 2y ago
      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.
      • kaashif 2y ago
        Stationery means more than just paper. I don't think there are any good synonyms for stationery, it's the only word with that exact meaning. Same problem when someone wants to substitute "login" for "authenticate" - not synonyms.
    • barrkel 2y ago
      The problem is the similarity of the words, not understanding the concepts.
      • Control8894 2y ago
• pquerna 2y ago
  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/ https://www.conductorone.com/ - to the people outside the IAM-geek space does this make more sense?
  • tracker1 2y ago
    I like the idea of exposing Roles for selection, and having those roles generally apply to permissions or workflows internally. This tends to work pretty well for many, or even most applications. I can't stand fine-grained access controls in general.
• zzo38computer 2y ago
  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.
• iamabdullahi 2y ago
  [dead]
• ern 2y ago
  It's one of the many reasons we have the saying, "Don't roll your own crypto. I remember when this saying referred to people rolling their own cryptography algorithms. When did it become about not doing your own auth? (I agree it's generally a bad idea, but curious about the scope expansion of the statement)
  • tracker1 2y ago
    Even then, I don't think it's quite the same... I've built several authentication and authorization controls, for the past decade mostly around JWT, but even then, I find more of the formal dedicated systems are often more complex than a given application needs, but it does take some understanding in terms of what to get right and getting what things wrong can be problematic. You can use some tools off the shelf, but may want other bits to be custom. For example, I've worked on several applications where an external provider winds up sending the user through an adapter to the application itself. So that external roles or groups can map to application roles. Especially if your application may be Azure AD for one client, and Okta for another. And another still may want you to provide something (simple user/password backed).
• redwoolf 2y ago
  I agree. I’ve never run into a situation in my professional work as a software engineer where there has been confusion about these two terms. The only problem I have is that I can never remember which one maps to HTTP status codes 401 and 403. But that’s just a personal quirk. Words mean specific things, let’s not dilute or overload the definitions of other words to avoid a confusion that may only exist in the mind of the individual writing the blog. We already have so many overloaded terms in software engineering.
  • cnity 2y ago
    > The only problem I have is that I can never remember which one maps to HTTP status codes 401 and 403. But that’s just a personal quirk. It's probably because the name of the codes is actually wrong. 401 is called "unauthorized" but actually means "unathenticated" in every situation I've seen it used. 403 is called "forbidden" which is fine, but is synonymous with "unauthorized" in this case.
    • 9Ljdg6p8ZSzejt 2y ago
      It isn't that the codes are named wrongly. 401 Unauthorized means you don't have permission to access the page, whether you're authenticated or not. 403 Forbidden means you can never access the page, regardless of permissions. This is typical in multi-tenant setups or when a site is never accessible to unauthenticated users. The distinction is subtle but important, and developers often misuse these codes, serving 403 Forbidden for authorization issues instead of indicating a permanent block.
      • cnity 2y ago
        The MDN docs state this about 401[0]: > Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response. [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#cli...
  • chuckadams 2y ago
• tryauuum 2y ago
  I don't really understand the point of using two words In daily life you wouldn't be implementing one without another anyway
• devjab 2y ago
  I completely agree with you, I also think that authenticate and authorise carry different meanings than permission and login. A login is an active thing that you do, but systems can authenticate you with things like single sign ons, so that you don’t actually “login” to many of the systems you want to be authorised in. Similarly permissions are the roles and claims your digital persona carries with it. These grant you permission to resources, but these can be trusted once your persona is authorised.
• m463 2y ago
  Years and years ago, when I was first learning secure networking, including ssh and ssl, I ran across auth and auth (authentication, authorization). I was confused and it wasn't until years later that I realized that the similar/identical terms stunted my growth.
• h1fra 2y ago
  I have implemented auth and auth multiple times in my life, and I'm still unsure which one we are talking about sometimes. Permissions and login might not be the best but they immediately brings clarity
• thih9 2y ago
  Also, when I forget which is which, or when I’m unsure which of these applies in a given case, I can just say “auth” and let others worry about that.
• sporkland 2y ago
  I came on to say much the same thing: a lot of authorization policies are very basic "is this a request by an authenticated user or service." But I also think the fact that they both get abbreviated to "auth" also causes a lot of bad mental modeling and poor communication.
• gofreddygo 2y ago
  "authorization" and "authentication" are poor stupid choice of words. They are long, not easy to pronounce, sound too similar, have the first 4 and last 5 characters the same, they mean wildly different things and yet get interchangeably used as "authn". If i give you keys to a room with the number 101 on it, is that authentication or authorization, or none ? If a gatekeeper says "sorry, invalid auth", what the f does that even mean? An expired token, is that authentication failure or authorization error? What about fake token ? A token with valid signature but wrong audience ? Its such a fu*ing mess.
  • 0xbadcafebee 2y ago
    > They are long, not easy to pronounce, sound too similar, have the first 4 and last 5 characters the same, they mean wildly different things and yet get interchangeably used as "authn". This is a complaint about the English language. We still use many English words that are confusing. The computer science department is perhaps not the best place to reform an entire human language. "AuthN" is shorthand for authe N tication. "AuthZ" is shorthand for authori Z ation. "AuthN+Z" is shorthand for something that provides both. > If i give you keys to a room with the number 101 on it, is that authentication or authorization, or none ? Authorization. To authenticate is to prove who you are. To authorize is to grant access. The key does not prove who you are, it proves you have access to the room. > If a gatekeeper says "sorry, invalid auth", what the f does that even mean? Means either authentication or authorization or both failed. This is a complaint about a stupid programmer who can't communicate properly, not with a word. Bet you a million dollars they'll output the error "invalid login" when it's actually a permissions issue (user can't log into this site/tenant/group/resource, not because the username or password was wrong, but because they didn't have the right role assigned). Changing the word won't make the programmer make fewer mistakes. > An expired token, is that authentication failure or authorization error? Authentication. 'Tokens' are not one thing (many things can be called 'a token' and be used in different ways... again, choose the right term to communicate properly), but generally speaking, 'tokens' are things you use to authenticate your identity, and the backend system matches the authenticated token with the authorized roles. > What about fake token ? A token with valid signature but wrong audience ? Authentication. Authentication and/or authorization (depends how your example works). > Its such a fu*ing mess. The concepts can be difficult to understand at first. Use them more and they make more sense.
• noashavit 2y ago
  Whatever the terms we use are we should definitely have 2 distinct terms to describe the process of proving you are who you claim to be and the process of determining what you can do once logged into the application. All two many developers and engineering leaders lump both concepts together as “auth” and falsely assume that both can be handled by their SSO service/ using a jwt.