Two different questions
Authentication answers one question: is this identity who it claims to be? A password, a hardware key, a certificate, a biometric check — these all establish identity. Authorization answers a separate question that authentication cannot answer on its own: given that this is who they say they are, what are they allowed to do right now?
A system can authenticate perfectly and still be insecure if its authorization is weak — for example, if every authenticated user, once logged in, can reach every action in the system regardless of role or need. Conversely, a system with fine-grained authorization gains nothing if its authentication is weak enough that an attacker can obtain a legitimate-looking identity in the first place. Both have to hold for the system to be secure as a whole.
Why the confusion causes real problems
Teams that treat 'the user logged in successfully' as equivalent to 'the user is allowed to do this' tend to build systems where authorization is implicit, scattered across the codebase as ad hoc checks, rather than centralized and reviewable. That pattern is hard to audit: there is no single place to look to answer 'who can do what,' only a collection of scattered conditionals that happen to enforce it, inconsistently, in practice.
Separating the two concerns explicitly — a clear authentication step, followed by an explicit authorization decision made against a defined policy — makes both easier to reason about and easier to change independently. Rotating how users log in should not require rewriting what they are allowed to do once they have.