Authentication versus Authorization

249,844

Solution 1

Authentication is the process of ascertaining that somebody really is who they claim to be.

Authorization refers to rules that determine who is allowed to do what. E.g. Adam may be authorized to create and delete databases, while Usama is only authorised to read.

The two concepts are completely orthogonal and independent, but both are central to security design, and the failure to get either one correct opens up the avenue to compromise.

In terms of web apps, very crudely speaking, authentication is when you check login credentials to see if you recognize a user as logged in, and authorization is when you look up in your access control whether you allow the user to view, edit, delete or create content.

Solution 2

In short, please. :-)

Authentication = login + password (who you are)

Authorization = permissions (what you are allowed to do)

Short "auth" is most likely to refer either to the first one or to both.

Solution 3

As Authentication vs Authorization puts it:

Authentication is the mechanism whereby systems may securely identify their users. Authentication systems provide an answers to the questions:

  • Who is the user?
  • Is the user really who he/she represents himself to be?

Authorization, by contrast, is the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system. For example, a database management system might be designed so as to provide certain specified individuals with the ability to retrieve information from a database but not the ability to change data stored in the datbase, while giving other individuals the ability to change data. Authorization systems provide answers to the questions:

  • Is user X authorized to access resource R?
  • Is user X authorized to perform operation P?
  • Is user X authorized to perform operation P on resource R?

See also:

Solution 4

In User Context:

Authentication = Verifying the User is who he claims to be (you can technically verify a lot of different things like password, tax info, social security info, driver's license, fingerprints, or other biometrics ... but usually a username/password is sufficient)

Authorization = Permitting the User to do something (you can set up roles ['admin', 'seller', 'buyer'...] with permissions ['access control center', 'delete products'...] and give those roles to the users, then validate the user has a role that permits him to do an action)

Permissions have a direct relationship with CRUD operations, so if building a UI, you can list objects as rows, and checkboxes in 4 columns for Create, Read, Update, Delete of that object permission for any given role.

Like in my example above 'access control center' is a full Create, Read, Update, and Delete access of the control center object, while 'delete products' is Delete access for the products object.

Note: HTTP Authorization Header was intended as permission to access a resource, but really is used as an authentication for all resource access.

It is easier in my head and in my code to think of verification and permissions because the two words

  • don't sound alike
  • don't have the same abbreviation
  • and actual implementation of authorization typically involves implementing Roles and Permissions

Authentication is verification and Authorization is checking permission(s). Auth can mean either, but is used more often as "User Auth" i.e. "User Authentication". A lot of times there is no explicit authorization implementation (roles and permissions), just the authentication is used to provide the authorization to do every available action. And so that is Auth.

Solution 5

The confusion is understandable, since the two words sound similar, and since the concepts are often closely related and used together. Also, as mentioned, the commonly used abbreviation Auth doesn't help.

Others have already described well what authentication and authorization mean. Here's a simple rule to help keep the two clearly apart:

  • Authentication validates your Identity (or authenticity, if you prefer that)
  • Authorization validates your authority, i.e. your right to access and possibly change something.
Share:
249,844
daGrevis
Author by

daGrevis

Hacker working with Clojure, Python, ReactJS and Docker. Enjoys r/unixporn and r/vim. Loves DotA 2, blues rock and gym. Really loves his girlfriend. https://twitter.com/daGrevis https://github.com/daGrevis https://news.ycombinator.com/user?id=daGrevis https://lobste.rs/u/daGrevis http://www.linkedin.com/in/daGrevis

Updated on July 08, 2022

Comments

  • daGrevis
    daGrevis almost 2 years

    What's the difference in context of web applications? I see the abbreviation "auth" a lot. Does it stand for auth-entication or auth-orization? Or is it both?

  • Suamere
    Suamere over 9 years
    The word "can" only applies to Authorization. Authentication has little or nothing to do with logging in. I could very well Authenticate that you are Boobalan in many ways (Not just username/password). Once I authenticate and know who you are, I could very well NOT Authorize you to log in, or do anything on my site. You are Authenticated, but you can't do diddley-squat. It's confusing and incorrect to use the word "can" when talking about Authentication.
  • Beachwalker
    Beachwalker over 8 years
    IMHO verification seems to have a slightly more open scope than authentication, even though authentication seems to be some kind of verification, not every verification is a authentication... so I would say a context is always needed: user access verification etc., authentication seems always to happen in the field of "is he really the guy/machine?" (hit me if I'm wrong, not a native speaker, but: "verify" the INFORMATION provided is accurate vs. authentications seems to have something to do with knowing the person/machine is the one he/it pretends to be)
  • Timo
    Timo over 6 years
    The definitions seem fine, but they certainly do not seem to be independent. As defined, does not authorization also imply authentication? How can you allow Adam's database delete operation if you doubt that he is Adam? Put differently, if Adam's delete operation is authorized, most hopefully that implies that Adam is authenticated.
  • Kerrek SB
    Kerrek SB over 6 years
    @Timo: An application will presumably want to do both, but they're orthogonal concepts regardless. Your boss could be reviewing the staff's authorizations to access critical components of the business, the company jet and the beer fridge without any concern for which particular individual on the CCTV feed matches the names in the spreadsheet. The latter would be the security guard's concern.
  • Ojonugwa Jude Ochalifu
    Ojonugwa Jude Ochalifu over 6 years
    This "answer" doesn't add anything to the answers already given.
  • devansvd
    devansvd over 6 years
    Sweet like a piece of Cake :)
  • David Brossard
    David Brossard over 5 years
    The concepts are definitely orthogonal. Authentication is not necessarily proving your identity. It could be proving a claim about yourself e.g. age. When you drink, you authenticate your age by showing an ID. Then you may be authorized to drink depending on your age and the jurisdiction you are in (you can drink if >21 in the US >18 in Europe)
  • King
    King over 5 years
    I like this, short and sweet.
  • Sinjai
    Sinjai over 5 years
    @DavidBrossard But how can you do comparisons on the age unless you know that is, in fact, his age? In other words, what good is authorization without authentication? How would you have checked his drinking age without first requiring him to authenticate himself?
  • Kerrek SB
    Kerrek SB over 5 years
    @Sinjai: I think the point is that those are orthogonal concerns, though, and they can be addressed by separate facilities: e.g. the (trusted) bouncer at the door can establish the client's age, and different services inside the establishment can have different age limits, but will all use the value they got from the bouncer to make admission decisions.
  • Jens
    Jens about 5 years
    Then I still don’t understand why an HTTP Authorization header carries authentication information… Isn’t that unfortunate naming?
  • Ryan Hansen
    Ryan Hansen about 5 years
    Another way to look at it (in the context of the barroom example) would be to consider that authentication is the process of matching the photo on the ID card to the person standing in front of you whereas authorization is the process of validating that their age meets legal requirements. In my opinion, the element in this mix that causes the lines to be blurred is that both tests must also be both cognizant of and hardened against forgery (is the ID a fake) which most people tend to view as a concern of authentication only rather than equally important to both auth-c and auth-z certification.
  • Per Lundberg
    Per Lundberg over 4 years
    @Jens Short answer: yes. Roy Fielding didn't knew better at that time... ;-) </tongue-in-cheek>
  • Minh Nghĩa
    Minh Nghĩa over 4 years
    @Jens I'm wondering that too. I find this answer's intuition helpful. As HTTP is stateless, authentication info must be sent along with every request, not just the starting and the closing requests (like, establishing a secure session, and send requests without auth in between). Therefore, that request header should be authorization, because it almost always carries other intentions (fetch data, img,...), not solely authentication.
  • d512
    d512 over 4 years
    I agree with @Timo here. Given these examples, I don't see how authorization has any practical meaning without authentication. Saying "we don't allow people under 21 to drink at this establishment" is fine but you can't actually apply that rule without talking about a specific person, which requires authentication.
  • d512
    d512 over 4 years
    Just keep in mind that authentication can be done in a lot of ways other than username and password such as fingerprints, facial recognition, SMS, etc. Thinking about it in those terms makes you realize that a password is actually kind of a weird way to authenticate someone. It assumes that you are the only person in the world that knows or could know your password. So if you know the password you must be who you say you are. Kind of a leap if you ask me.
  • d512
    d512 over 4 years
    On the other hand, imagine a scenario in which you have absolute trust that nobody will lie about their identity. So when a user logs in they just type "jsmith123" without a password or any form of authentication and the system happily lets them in knowing they are who they say they are. So there is no authentication but they still may need to be authorized so they don't perform tasks they aren't allowed to perform. So I guess that's a scenario where authorization exists without authentication...hm...¯\_(ツ)_/¯
  • DiSaSteR
    DiSaSteR about 4 years
    Think that you work in a place where you need a plastic card pass to get in. I would steal your pass and still autorize opening doors that you are authorized to open. But the authentication failed, because some guard should at least compare my face with the photo on the plastic card pass.
  • ansh sachdeva
    ansh sachdeva almost 4 years
    This is a very informative answer covering technical aspects. Thank you!
  • Khoa Vo
    Khoa Vo about 3 years
    @d512 The terms talk about different processes. You can say that "house" wouldn't mean anything if "people" didn't exist but that's completely pointless because everything exists and everything has a name and everything is related to everything else, so what's the fuss?
  • Aditya Mittal
    Aditya Mittal over 2 years
    Yes, I'm talking in the context of 'the User.' In other contexts, all the terms can mean other things.