Two questions, not one
When you sign in to a work system, two separate questions are being answered. First: are you really who you say you are? Second: given who you are, what are you allowed to do here? The first is authentication. The second is authorization. They happen in that order, they use different information, and they fail in different ways.
The words look similar and are often shortened to “auth”, which does not help. This article uses everyday comparisons to keep them apart, then looks at why mixing them up leads to gaps. It is general information, not security advice.
Everyday examples
The hotel
At a hotel front desk you show identification and are given a key card. Showing identification is authentication: the desk is satisfied that you are the guest who booked. The key card then opens your room, the gym and perhaps the lift to your floor, but not other rooms or the staff office. That limited set of doors is authorization. Being a verified guest does not mean you can enter any room.
The office building
A staff pass proves you work for the company, so the front door opens. Inside, the server room has a separate lock that only some people can open. The first check established identity; the second checked permission.
A shared document
You log in to a document tool with your work account. The log-in is authentication. The document owner has shared one folder with you as a viewer. You can read it but not edit it. That setting is authorization.
Authentication in more detail
Authentication is about evidence. Typical evidence falls into a few categories:
- Something you know, such as a password or PIN.
- Something you have, such as a phone or a hardware key.
- Something you are, such as a fingerprint.
Using more than one category makes it harder for someone else to pass as you, which is the idea behind multi-factor authentication. Authentication does not say whether the person should be trusted with anything in particular. It only establishes, with a degree of confidence, which identity is present. No method is perfect, and stronger checks usually add some friction for users.
Authorization in more detail
Authorization is about rules. After the identity is known, the system consults those rules to decide what the identity may view, create, change, approve or delete. Rules can be built in several ways:
- Permissions assigned directly to an individual.
- Permissions grouped into roles, so a person receives what the job needs. Role-based access control is the common version of this.
- Rules based on attributes, such as department, location or time of day.
Whichever approach is used, a good design gives people only what they need, which is the idea behind the least privilege principle.
Why the difference matters
Confusion causes real gaps. Some typical patterns:
- Treating login as permission. If a system only checks that someone is signed in and never checks what they may do, any authenticated user can reach everything. A person might then open records belonging to other departments simply by guessing a web address or changing a number in a link.
- Strong login, weak permissions. An organization may invest in sign-in security while leaving permissions broad. A properly verified user with too much access is still a risk, whether through error or misuse.
- Assuming a leaver is handled once the login is disabled. If other credentials, such as access tokens or shared accounts, remain valid, authorization may still succeed in places. This is part of why careful handling of joiners, movers and leavers matters.
- Mixing responsibilities. Teams that treat both as one topic may leave nobody responsible for permissions, even though the identity team looks after logins.
- Single sign-on misunderstandings. With single sign-on, one login reaches many applications. It simplifies authentication, but each application still has to decide what that person can do inside it. Assuming that central login handles permissions everywhere is a common mistake.
How the two relate in a central setup
In a central IT environment, authentication is often handled in one place, by an identity service the whole organization uses. Authorization is frequently split: some rules are held centrally, for example group memberships, while the details inside each application are controlled by that application’s owner. This split is sensible, but it only works if owners are clear about their part. Decisions about who approves what are a matter of decision rights and system ownership.
The arrangement also has a trade-off. Central authentication means one place to secure and monitor, but it also becomes a dependency; if it fails, people cannot sign in anywhere. Local authorization gives system owners flexibility, but without periodic access reviews, permissions can drift.
Practical questions to ask
When looking at any system, it can help to ask separately:
- How does it confirm identity, and how strong is that check for the data involved?
- Where are permissions defined, and who can change them?
- Does every action check permission, or only the first login?
- Who reviews the permissions, and how often?
- What happens to both when a person changes role or leaves?
Keeping the two questions apart does not make a system secure by itself, but it helps teams talk about problems precisely. For decisions about real systems, involve qualified security professionals who can assess the specific risks.