You have entered your password correctly. You have done the two-factor authentication dance: the code from your phone, the tap of the button. Your name is in the system. And then the screen says: You do not have permission to access this resource.
This happens constantly, in every organization that uses more than one system. And the reason it trips people up is that most of us treat "logging in" and "being allowed to do something" as the same thing. They are not. They are two completely separate questions that every computer system answers in sequence, and confusing them leads to the wrong fix, every time.
Two Questions Every System Asks
Every time you try to access something, from a work laptop to a company portal to a shared file, the system is really asking two things, in this order:
- Who are you? This is authentication (often shortened to "authn").
- What are you allowed to do here? This is authorization (often "authz").
The words sound similar. The mechanisms behind them are completely different. Mixing them up is one of the most common mistakes in IT troubleshooting, and understanding the gap makes you a sharper thinker about anything involving computers, accounts, or access.
Authentication: Proving You Are Who You Say You Are
Authentication is the process of verifying your identity. The system is asking: "Are you really you?"
You prove this by presenting something the system can check against a record it already holds:
- Something you know: a password or a PIN.
- Something you have: a one-time code from an authenticator app, a hardware security key, a smart card.
- Something you are: a fingerprint or a face scan.
When you type your password and then enter the six-digit code from your phone, that is authentication happening in two layers. This is two-factor authentication (2FA): the system asks for two independent proofs, making it much harder for someone who stole your password to impersonate you, because they would also need your physical phone.
Authentication ends the moment the system decides it believes you. At that point, the system says, in effect: "Yes. I know who you are. Come in." The gate opens. You are now inside the building.
But being inside the building is not the same as having a key to every room.
Authorization: Deciding What You Can Do
Authorization is what happens next. Now that the system knows who you are, it checks what you are permitted to do.
This is governed by rules, roles, and policies that exist independently of your identity. Authorization answers questions like:
- You are on the Finance team, so you can read the budget spreadsheet but not edit it.
- You are a junior administrator, so you can reset passwords but not delete accounts.
- You joined the company last week, so you have not yet been added to the project shared drive.
You can be perfectly authenticated (the system knows exactly who you are) and still be unauthorized (you have no permission for the specific thing you are trying to do). The login succeeded. The action was blocked. These are different outcomes with different causes, and they require different fixes.
The Hotel Key Card
This is the analogy that makes the distinction click for most people.
When you check into a hotel, two things happen.
First, you show your ID at the front desk. The staff member checks your face against your passport, finds your booking in the system, and confirms you are the person who made the reservation. That is authentication. They now know who you are. You get a key card.
But the key card is not a master key. It opens your room (say, Room 412). It might also open the gym and the parking barrier. If you walk up to the penthouse suite and tap your card on the reader, the door stays shut. Not because the card is fake. Not because the hotel does not know who you are. But because you have not been authorized to access that room. You are a verified guest. You are simply not this room's guest.
That separation is authorization at work. The identity check and the access check are two separate systems, controlled by two separate decisions made at two different times by two different people.
In computing, your user account is the key card. The identity provider (Active Directory at most large organizations, or Azure AD, Google Workspace, Okta, and so on) is the front desk. The files, applications, and systems you can reach are the rooms. Who decides which rooms you can enter? Usually a combination of group memberships, roles, and access policies that an administrator configures, often completely separately from the person who created your account in the first place.
What This Looks Like in Real IT Work
I run into this distinction daily in support work, and the confusion costs real time on both sides of the ticket.
A new employee joins. Their account is created. They can log in without any problem. But they cannot open the shared drive their manager mentioned, cannot reach the ticketing system, cannot see the project folder in the CRM.
The instinct, for both the user and the help desk, is to assume something is broken with the login. But the login is fine. The user is authenticated. The missing piece is authorization: no one has added their account to the relevant security groups, assigned the right application roles, or shared the folder with them yet. The identity check passed. The permission check has nothing to act on.
Resetting a working password does not solve a permission problem. Raising a ticket titled "I can't log in" when the correct description is "I don't have access to Resource X" routes to the wrong team and adds an unnecessary back-and-forth. The first diagnostic question for any "I'm logged in but can't access this" ticket is: is this a missing permission, or is there a genuine problem with credentials? Those are two different investigative paths, and knowing which one you are on saves roughly half the resolution time.
Why the Distinction Matters Beyond the Help Desk
The authentication vs. authorization split matters for security too, and understanding it changes how you read the news about breaches.
Authentication failures are what phishing and credential-theft attacks exploit. Someone steals your password (or tricks you into handing it over) and impersonates you. The fix involves stronger passwords, MFA, and monitoring for suspicious login locations. The attacker's goal is to pass the identity check.
Authorization failures are a different class of problem. They often surface as over-permissioned accounts: employees (or former employees whose accounts were not properly deprovisioned) who can access systems or files they have no business reason to touch. The attacker, or the curious insider, does not need to break anything. They log in legitimately, then find that authorization has been granted far more broadly than it should be.
The security principle called "least privilege" is entirely about authorization: give every account only the access it actually needs for its current role, nothing more. That is not an authentication problem. It is a permission design problem. Two different threat models, two different mitigations, two different words for a reason.
The One-Line Test
Next time you hit an "access denied" error (or someone brings one to you), try this question: Did the system recognize me, or did it recognize me but decide I am not permitted?
If the system did not recognize you, that is an authentication problem. Check your credentials, check MFA, check whether the account exists and is enabled.
If the system recognized you fine but refused the action anyway, that is an authorization problem. Check what groups or roles the account belongs to, check whether the resource has been shared or assigned, check whether any conditional access policy is blocking the specific action.
Same error message on the surface. Completely different root cause underneath. The words exist precisely so you can tell them apart.
If any of this maps to something you are trying to figure out in your own environment, drop me a message. Happy to talk through it.
Comments