Authentication versus Authorisation
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.
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.