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?
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.
401 Unauthorized error code and annoys me that it's not 401 Unauthenticated.
– Drew
Oct 25 at 16:27
Authorization and Authentication are two sides of the same coin where authorization is sometimes dependent on authentication but not always. How?
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.
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.
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:
Authentication is like having a key card to a building.
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.
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.
