I have referred this link and I know that

Authentication = login + password (who you are)

Authorization = permissions (what you are allowed to do)

My question is: Suppose A gets the login id and password of B which has higher authority than A, that would compromise authorisation because once A gets falsely authenticated as B, A gets all the access privileges of B.

So what is the whole point of authorisation?

Is it dependent or independent of authentication?

  • 3
    Let's flip the script a bit - there is User C. That user gets promoted and is allowed to do more in the system. If you don't have separate authorisations, then you need to create an entirely different user for them on the system. Then you have User D who gets demoted. You shout take away some of their rights on the system. Again, without authorisation, you can't do it and let them still use the same login for the system. – VLAZ Oct 24 '19 at 19:04
  • 3
    a theoretical system that only had authentication system but no authorisation system would be a system that allows everyone to access everything. Everyone is a superuser of the system and can modify everything that can be modified in the system, including pretending to be another users and changing another user's data. – Lie Ryan Oct 25 '19 at 2:44

12 Answers 12


once A gets falsely authenticated as B...

On any minimally secure system, this isn't how it happens. From the system's point of view, User B is authenticating himself, not User A. It was not falsely authenticated, it was using the real login and password. It's simple case of Credential Theft. You could harden the system using any form of 2FA, but the system is working as intended.

It would be falsely authenticated as you said if User A uses his own credentials and somehow ends up with the profile of User B. In this case, the attack could be an Authentication Bypass, or Privilege Escalation, and the system would have to be patched.

So what is the whole point of authorization?

Separating privileges depending on who you are. If someone can use your credentials, it is essentially you, so authorization still holds.

It is dependent or independent of authentication?

It is independent (though many authorization systems choose to depend on authentication information). Authentications is about who you are. Authorization is what privileges you have. Single Sign-On systems, for example, are used to enforce identity, and another system have to be used to enforce permissions.

  • 1
    I was going to comment the same thing. If you are actually able to authenticate as another user WITHOUT EXPLOITING any other vulnerability that actually allowed you to do so, there is no authentication nor authorization issue in the application. If with your user A you manage to acquire users B user and password and THEN use those credentials to authenticate, you found an authorization issue, as with A's access, you were able to escalate to B's (higher authorization). – BBerastegui Oct 23 '19 at 16:48
  • 4
    Tangential note: this always reminds me of the 401 Unauthorized error code and annoys me that it's not 401 Unauthenticated. – Drew Oct 25 '19 at 16:27
  • @Drew Unauthorised is technically correct. As the assumption on most HTTP requests is that they allow anonymous users. Thus anonymous users are unauthorised to access that resource. How you can become authorised is tangential and out of the scope of the response. – Vality Oct 25 '19 at 18:05
  • 1
    @Vality Shouldn't that return 403 forbidden? (Which should also be called 403 unauthorized then.) – Drew Oct 25 '19 at 18:43
  • @Drew Forbidden is even more vague. It could mean the resource is blocked in your country, it could mean they blocked it because they dont like your browser. Or even because they dont allow IP addresses ending in a 6 to access it. Unauthorised explicitly means its about your identity, forbidden just means for some reason your not allowed to view it but the reason could be nothing about you – Vality Oct 25 '19 at 18:52

Authorization and Authentication are two sides of the same coin where authorization is sometimes dependent on authentication but not always. How?

  1. Even without a login , a visitor to Stack Exchange can view questions and answers. Here the visitor has authorization to view answers but surely doesn't need authentication for that, hence here authorization is independent of authentication.

  2. A logged-in user has authorization to post any questions or answer a question, but for that they need to provide proper login hence here authorization is dependent on authentication.

In short, of course if authentication is compromised then it will also hamper authorization.


Generally speaking, it's a good idea to consider all the four As (Authentication, Authorization/Access Control, Accounting, Auditing) rather than just two.

There is no method of authentication that can reliably counter the $5 wrench method (as described by the webcomic XKCD, that's where you hit someone with a $5 wrench until they log in for you) although there are methods (such as passcode+1) that can alert the system that the $5 wrench is being used. It's a wicked world.

Authentication is the only step that is not dependent on the others. That means it has to come first. Authentication can be explicit (tell me who you are) or implicit (I see by your hardware certs that you have logged in from inside the bunker). You can authenticate as an individual (Consultant Rin) or as a "role" (any murderbot). Legally regulated enterprises are nearly always required to use explicit individual authentication so that auditing has a chance of working. If a group or role account seems necessary, something is probably wrong with your understanding of the problem, because there will be another solution you simply aren't seeing.

Authorization (which is often called Access Control because it's really easy to mix up authentication and authorization when speaking) is the granting of rights to a process (logged in users are just another process from the processor's point of view) based on their authentication. For example, if you are J. Random Lusr, you might only get the right to create files in your home folder. But if you are Biff Snidely, corporate aristocrat, you might also get the right to create files in a shared department folder. You may be subject to limits on disk space or other resources, or not.

Accounting is basically the recording of what resources a logged-in process has used - it can be very simple (Joe used 1000 processor cycles today and has used 1G of storage) or very elaborate (Biff issued these commands in this order at precisely these times). It is the basis of auditing. Extremely good accounting will send data off the system, so that it cannot be deleted from the local system if it is hacked.

Auditing is more loosely defined; this can be an automatic process that looks out for attempts to perform actions the user is not allowed to perform, or it can be a team of gnomes chained up in the basement poring over the day's command logs, or whatever else you can think of. The point of auditing is that authentication can be defeated by a $5 wrench, so you can't just assume that because your users have hard passwords nobody has ever broken your security. You can't even assume your users will not find a way to break access controls by accident, really, that happens all the time.

  • 1
    Also besides the 5$ wrench method there is the discreet envelope method, which, while somewhat more expensive (or not; wielders of 5$ wrenches tend to cost quite a lot), tends to avoid the alerts as the user is abusing their privileges willingly in that case (and many other). – Jan Hudec Oct 25 '19 at 21:00
  • Good point, @JanHudec! There's also shoulder surfing and many other means... I tried to do a broad overview so the questioner would see the Nirvana Fallacy (en.wikipedia.org/wiki/Nirvana_fallacy) implicit in the question, and I had to lose some detail! :D – Medievalist Oct 25 '19 at 22:09

Another thing to consider also is that the assumption the OP is making: "once A gets falsely authenticated as B, A gets all the access privileges of B." is not necessarily correct in all systems and use cases.

For example, in a system with a dual control workflow, I have to authenticate first but then also be granted a permission to a specific resource from its owner. The owner may or may not grant me that authorization according to many other factors apart from me being authenticated, for example some resources should only be accessed during specific times of the day.

A good analogy that I use to think about the subject is this:

  1. Authentication is like having a key card to a building.

  2. Authorization is which rooms in the building I can access once I'm in, in particular if my building card was stolen and I approach a room that is guarded by someone who doesn't recognize me I may not be allowed inside :)


Your question does highlight the need for robust authentication mechanisms, and the reason why many for some time have considered the password a 'dead' control. Further this is the reason multi-factor authentication is gaining adoption.

Let's spin your question around though: Suppose an org has a system that hosts financial HR, administrative, and other information. Now person A is authenticated (correctly) and she is authorized to only see administrative information. If we were to take your argument and say, "well we can't trust our authentication so let's not bother with authorization" you would give person A access to financial, HR data even though she shouldn't be authorized to see it.


Authentication answers this question: Are you who you say you are? Numerous ways to do this, but how is irrelevant. Some ways are obviously more effective or reliable than others. You can also look at it as two questions: Who are you? How can I be sure?

Authorization answers one of these questions: What are you allowed to do? Are you allowed to do X? You can do this without Authentication, but why would you? What's the point?


To me, the simplest explanation is as follows:

Authentication tells the system who you are. Authorization tells the system what you can do.

If client A got the login and password of B and managed to authenticate as B, for all intents and purposes to the "fooled" server, A is now B and is authorized to do whatever B can do.

Although authorization works independently from authentication, I would argue that authentication is a prerequisite for authorization - how can the system know what you can do if it does not know who you are?


Authorization/Authorisation is dependent on Authentication, but they are still completely different concepts simply because Authentication methods vary according to the levels of Authorization.

You might be able to bypass authentication and authorise yourself as a normal user, but in order to reach root access, you might have to go through multi factor authentication.


My question is: Suppose A gets the login id and password of B which has higher authority than A, that would compromise authorisation because once A gets falsely authenticated as B, A gets all the access privileges of B.

Not necessarily. Authorization can be tied into any number of things. For example, User B may get different authorization profiles based on the type of device (computer vs. mobile device). Or they may have different profiles depending on the how they are connected to the network (wired vs. wireless vs. VPN, corporate headquarters vs. branch office, etc). Or, as a final example, the date/time may determine what authorization profile is applied to the user.

So just because User A can use User B's credentials, doesn't necessarily mean they will get the same privileges.

So what is the whole point of authorisation?

It allows you to centrally administer what a user/device can do depending on a wide number of factors. It allows you to consistently and more reliably apply privileges to users.

Say an employee's job responsibilities change (they get promoted, position gets modified, etc) and you need to adjust privileges. You could do so by "touching" each resource they need to have their privileges changed. Or if all those resources were using a central AAA server, simply changing the privileges centrally will grant them those privileges quickly and easily (and less prone to missing resources or human error when making repetitive changes). Often this is as easy as changing/adding a group membership to their user account.

Or say you have several employees that should have the same privileges. They can all share the same authorization profile. Again, simpler to manage and make sure that their experiences are all consistent.

Is it dependent or independent of authentication?

In some senses, both. Authorization takes place after authentication, so on the one hand it doesn't take place until authentication takes place (even if it is an "open authentication").

On the other hand, authorization is an entirely separate process than authentication. The authentication may or may not determine what authorization profile is applied.

  • It seems you are answering a different question, namely "what is the benefit of centralized authorization". Authorization is not necessarily centralized (though it is often a good idea for it to be). – sleske Oct 24 '19 at 11:39
  • @sleske, whether it is centralized or local, most of the answer still applies. You can provide localized policies that apply to groups of users. These are just far more prone to human error and issues as you scale up than centralized solutions when replicating across an increasing number of resources. Additionally, centralized solutions tend to offer more in the way of creating very specific policies based on a wider number of criteria than local solutions. Frankly, I know of very few organizations of scale that aren't using centralized AAA of some sort (even if it is only MS AD). – YLearn Oct 24 '19 at 19:14

Your hypothetical doesn't really make sense. You're saying that something is compromised because someone got someone else's credentials that have more authority than their own. It is compromised merely because someone got someone else's credentials alone. Whether they have higher, the same, or less authority shouldn't matter.

Think of a situation where an admin gets a regular user's credentials. Now they can impersonate that user. Before, sure, maybe they could do things "as" that user but presumably there are logs somewhere that someone could audit to see that it was the admin acting as the user. If someone has that user's credentials though then the logs will show that it was the user.

The point of authorization still remains. Different users need to be able to perform different things and without authorization that cannot be accomplished.

As amit thakur says in their answer, even unauthenticated users have authorization to perform some tasks like viewing questions and answers on this website when you are not logged in. So authorization and authentication are separate concepts but closely related.


Imagine you stay in a building that has many apartments, the security man at gate knows that you actually live there but does not know the exact apartment you live in, Authentication happens at the point when the security man identifies you as someone living in the building and allow you to go in.

However, you gaining entrance into the building does not mean you can enter any apartment you see. Therefore, authorization happens when you access your own apartment because that's what you've been approved to access.


(potentially unpopular opinion ahead!)
In a particular aspect, authorization can be seen as an elevated authentication. An authentication is a validation of identity, and an authorization is a validation of its attributes.

In PKI, Attribute certificates work hand in hand with identity certificates to provide authentication then authorization. An identity certificate is like the passport and an attribute certificate is like the visa.

  • "authorization is a validation of its attributes" your answer depends on this line, but it is unexplained. The PKI example is a logic loop since "attribute certificates" when used for authorization, are called "authorization certificates". This does not make this an opinion, and hence, not an unpopular opinion, since you are quoting the RFC, but it does make this answer rather nebulous without more explanation. – schroeder Oct 24 '19 at 15:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.