Authentication Does Not Authorize Anything

“They signed in with MFA, so they can use the admin screen.”

Let me stop you there, before this becomes a policy exception with a cheerful green checkmark beside it.

Authentication is not authorization.

MFA establishes that a claimant completed an authentication ceremony.

Your admin screen is a resource.

Opening it, changing it, reading its data, administering its settings.

Those are operations.

Operations need entitlements and a policy decision.

You would never say “the receptionist saw my badge, so I can rewire your data centre.”

Put the badge behind SSO and apparently every door in the building becomes the same door.

It doesn’t.

Identity proofing asks whether the person is who your organization says they are, before an account exists. NIST SP 800-63A calls its three levels IAL1, IAL2 and IAL3.

Authentication asks whether your claimant controls an accepted credential.

Authorization asks whether that principal may perform this operation, on this resource, now.

Different questions.

Different controls.

Keep them apart.

1. “But the Admin Screen Is Behind SSO.”

Yes.

SSO means your user signs in to your identity provider, and assertions are then presented to relying parties without another interactive login.

That is a useful reduction in repeated prompts.

It isn’t a blank cheque signed by your application.

The relying party still has to decide what the recognized identity may do. Your IAM flow is explicit about this: SSO decides who the person is.

The relying party, or an entitlement layer in front of it, decides what that person may do once recognized.

Your application has more than one decision to make.

Can this principal view the admin screen?

Read this tenant’s audit log?

Change a billing setting?

Approve a privileged role?

A valid SSO session answers none of those on its own.

SSO is an authentication handoff. Authorization is an application or policy-decision function.

Putting a sign-in page in front of the admin screen does not turn the sign-in page into an access-control matrix.

A lobby isn’t a key ring because it has a nice badge printer.

2. “But the Identity-Provider Group Says Admin.”

Then somebody still has to explain to you what Admin means.

RBAC assigns permissions to roles, and individuals to one or more roles. Your model was formalized in 1992, extended in 1996, unified by NIST in 2000, adopted as ANSI/INCITS 359 in 2004, and revised in 2012.

Its useful administrative property is exactly that: a role maps people to a named set of privileges.

Notice what it doesn’t say.

It does not say a group label causes a permission to materialize in every connected application.

The group has to be mapped to a role.

The role has to have defined permissions.

Your application has to enforce those permissions for the operation, and, where it matters, for the object being operated on.

That mapping is where least privilege either exists or doesn’t.

NIST defines least privilege as restricting users or processes to the minimum access necessary for assigned tasks.

RBAC does not invent that discipline.

It enforces whatever broad or narrow role somebody configured.

A group is an attribute. A role is an entitlement construct. A permission is what an enforcement point actually allows.

If your directory group named Admin maps to everything, the system has not become simpler.

You have put the word “Admin” on the box containing everything.

3. “But the User Passed Phishing-Resistant MFA.”

Good.

Use it.

WebAuthn and FIDO2 improve the authentication step, because your credential is bound to the relying-party origin.

At registration, your authenticator creates a public/private key pair for that specific site.

The relying party stores the public key.

The private key never leaves the authenticator.

At sign-in, it signs a random challenge for your actual RP ID.

Which is why NIST SP 800-63B’s AAL3 requirement for verifier impersonation resistance is about protocol properties, not about how sincerely somebody clicked “approve.”

A TOTP or SMS code is a shared secret, valid for a short window.

A push approval supplies no binding to the site that triggered it.

Both can be relayed against you.

An origin-bound WebAuthn assertion cannot be repurposed for a fraudulent origin.

Excellent.

You have a more resistant proof of the claimant.

It still doesn’t establish that the claimant belongs in an administrator role.

A hardware key is not a ceremonial sword.

Holding one does not make you king of production.

4. “But the Application Checks the Role in the Token.”

Better.

Now keep reading the claim, instead of treating its first noun as a complete architecture.

A role claim in your token can participate in authorization. The decision is still: may this subject perform this operation, on this object, under these conditions?

RBAC handles your coarse answer.

Identity assigned to a role, role assigned to privileges.

ABAC handles conditions at request time, using subject, object, operation and sometimes environment attributes.

NIST SP 800-162, first published in January 2014 and updated in August 2019, defines ABAC around exactly that evaluation.

“Member of Admin” might be relevant.

So might the target tenant.

The requested operation.

The record’s classification.

The device condition.

Your environment.

Most enterprises layer RBAC for baseline access with ABAC or a policy layer for finer decisions.

Your token also has a destination and an intended use.

A short lifetime reduces the period in which a stolen session credential stays useful. It does not make a token for one service a permission to call another.

Validate your token’s intended audience and scope.

Then evaluate the role and object policy at the enforcement point.

A signed token is evidence. It is not an authorization result detached from the request.

5. “But We Only Have One Administrator Anyway.”

Then that person can request elevation when you have administrative work to do.

Standing privileged access is the thing privileged-access management exists to eliminate.

It is what you are describing.

Just-in-time access grants privilege for a specific task and revokes it immediately afterwards, rather than leaving an administrator role active around the clock.

Microsoft Entra Privileged Identity Management implements the pattern with eligible roles, activation requests, a bounded window and approval workflows.

This isn’t bureaucracy for its own sake.

A permanent role expands the window in which a valid privileged account can be exploited.

JIT narrows it.

The person is the same person.

Their authentication assurance is unchanged.

Their entitlement is deliberately different before, during and after the task.

The emergency exception is separate.

A break-glass account exists for when your ordinary approval channels fail. You control it through detection: every use logged, every use reviewed afterwards, because your account exists to bypass the normal gate.

Treat break-glass and JIT as the same control and both become a permanent exception with better branding.

6. “But Adding a Separate Authorization Check Will Slow Every Request.”

Your request already needs an answer about the resource and the action.

Skipping the answer doesn’t make it fast.

It makes it implicit, broad, and difficult to review.

For a coarse decision, you evaluate the assigned role’s permissions. For a sensitive or object-specific decision, evaluate the relevant subject, object, operation and environment attributes.

Those are different layers of the same authorization function.

They are not competing login experiences.

The bad alternative is familiar.

Authenticate once.

Attach a generous group claim.

Hope every endpoint means the same thing by “admin.”

Then an administrative interface gains new actions.

Or a tenant boundary appears.

Or a service gets connected later.

And the old claim quietly authorizes something nobody reviewed.

The authorization check belongs where the resource and operation are known, in your application, or its policy decision point.

The IdP proves a claimant.

The enforcement point decides whether that claimant may do this.

That distinction isn’t latency.

It is the difference between a decision and a commemorative stamp from the login screen.

7. No, This Does Not Mean Strong Authentication Is Optional.

It isn’t.

You still need strong authentication.

Passwords, TOTP and SMS codes, and push approvals all leave a reusable secret or approval that a fraudulent party can relay.

WebAuthn’s origin binding prevents that particular theft, because the private key is never transmitted and the assertion is bound to the actual relying-party origin.

But your authentication has a boundary.

A session cookie issued after a successful sign-in represents “this request already authenticated.”

It does not record whether your login used a password, an OTP or a hardware passkey.

So a stolen session token can inherit the session without defeating your original factor.

Microsoft documented AiTM kits targeting more than 10,000 organizations since September 2021, and conversion of stolen sessions into business-email-compromise fraud in as little as 5 minutes.

Its guidance is blunt: the attacker gets authenticated to a session on the user’s behalf, regardless of the sign-in method.

Your defensive response at that layer is session management.

Short token lifetimes.

Device or IP binding.

Anomaly detection.

Token revocation.

It isn’t pretending the factor assigned the principal a role.

Authentication assurance answers how the claimant proved control. Authorization answers what the principal may do.

Neither answer replaces the other.

8. What You Should Actually Do

Define permissions as resource-and-action pairs, separate from sign-in policy.

“Can access the admin screen” is already too vague if that screen can display reports, change configuration, approve roles and administer tenants.

Name the operations and the objects they affect.

Map directory groups to bounded RBAC roles. Use ABAC or a policy layer where the decision depends on subject, object, operation or environment attributes. Enforce the role and object check where the requested action is visible.

Issue short-lived tokens with explicit audiences and scopes, and validate them at the service that receives them.

Do not treat signature verification as permission evaluation.

It proves the issuer made a statement.

It does not establish that the statement authorizes this action on this object.

Use phishing-resistant authentication for sign-in. Use JIT activation and approval for ordinary administrative work. Keep a separate break-glass procedure whose use is logged and reviewed.

That is several controls at several layers.

Yes.

That’s what an access system looks like when the nouns mean different things.

9. The Entitlement Has a Lifecycle, Even When the Login Does Not.

At hire, an HRIS record can trigger directory provisioning and birthright access, the baseline entitlements for a role or department, with a request path for anything beyond it.

Research puts the average at 6 days for a new hire to receive full productive application access. Largely because many entitlements still need manual approval rather than birthright rules.

At a role change, your grant and your revoke are separate operations.

Grants happen, because absence is conspicuous.

Revocations don’t, because unnecessary access is quiet.

That is how you get entitlement sprawl: the visible accumulation of permissions from prior roles.

At departure, disable the IdP account, then explicitly revoke access in systems outside its reach.

Local database accounts.

VPN concentrators.

The average number of applications deployed per Okta customer passed 100 in 2025, up 9 percent year over year.

An IdP disable reaches only the federated subset.

Deprovisioning is a checklist, not a button.

It won’t press itself.

Review your entitlements on a fixed cadence.

Microsoft Entra supports weekly, monthly, quarterly and annual access reviews, and its inactive-user recommendation appears after 30 days without a tenant sign-in.

That is evidence for review.

Not a mystical proof that the permission was harmless, or necessary.

10. The Actual Model Is Not Complicated.

Identity proofing says whether your person corresponds to a claimed real-world identity.

Authentication says whether your present claimant controls an accepted credential.

SSO carries that result to your relying party.

Authorization evaluates entitlements, resource, action and relevant context.

IAM manages how those entitlements are granted, reviewed, elevated and revoked.

MFA tells your service how confidently it recognized a claimant. It does not tell your service what that claimant may do.

Use strong factors.

Use SSO.

Use roles.

Use attribute policy.

Use explicit resource-and-action checks.

Use JIT privilege.

Revoke access when roles and employment change.

They aren’t duplicates.

They are the load path from “this person signed in” to “this operation is permitted.”