Authentication and Authorization Answer Different Questions

Identity systems become easier to reason about when you separate the questions.

Identification

Which account or identity is being presented?

Example:

account = bob

Authentication

What evidence convinces the system that the presenter controls or represents that identity strongly enough for this context?

Examples can include passwords, hardware-backed credentials, one-time factors, certificates, or other mechanisms.

Authorization

Given the authenticated identity and current context, is this specific action allowed?

Example:

bob → operator role → may update match notes

These are separate decisions.

A successful login does not imply universal permission

Fictional role map:

alice → viewer
bob → operator
coach → admin

Sensitive actions:

read_status
update_match_note
change_user_role
restore_backup

Possible authorization matrix:

Now a login event is only the beginning of the authorization story.

Put authorization near the action

A dangerous design is:

user logged in → therefore all application actions allowed

A stronger design checks authority when a protected operation is requested.

Pseudocode:

if not session.authenticated:
    deny("authentication-required")

if not may(session.role, "update_match_note"):
    deny("not-authorized")

perform_update()

This is not production code. It is a mental model showing that authentication and authorization are distinct gates.

Default deny makes the policy easier to inspect

Instead of allowing everything except known bad cases, a role model can explicitly allow documented actions and deny others.

if action in allowed_actions_for_role:
    allow
else:
    deny

The exact policy language varies by system, but the principle is useful: authority should be granted intentionally, not inherited accidentally.

Multi-factor authentication changes authentication strength, not authorization scope

Suppose Alice uses two authentication factors.

Alice is still a viewer.

MFA may increase confidence in the authentication event under the stated threat model. It does not automatically make Alice an operator or admin.

This distinction prevents a common misconception:

stronger authentication ≠ broader authorization

Supplied evidence

12:01:11 event=login account=alice result=success method=training-mfa
12:01:18 event=action account=alice action=update_match_note decision=deny reason=role
12:01:31 event=action account=alice action=read_status decision=allow

A defensible interpretation:

The supplied log shows a successful authentication event for fictional account Alice followed by a denied update action and an allowed read action, consistent with the stated viewer role policy.

Do not claim the human behind Alice is unquestionably identified. The log represents system decisions in a fictional model.

Activity: build an authorization matrix

Use at least four roles/identities and six actions.

For every allowed cell, ask:

Why does this role need this action to perform its required function?

If the answer is “just in case,” that permission deserves review.

Negative tests are essential

Security controls are not proven by allowed actions alone.

Test:

• viewer can read status;
• viewer cannot update;
• operator can update;
• operator cannot change roles;
• admin can perform documented admin function;
• unknown/unauthenticated session cannot perform protected actions.

Then record the decision evidence.

Start your Identity and Authorization Evidence Map

Include:

Identity/account
Authentication evidence represented
Role
Required actions
Prohibited actions
Authorization decision point
Decision log/evidence
Negative test

Lesson 2 adds sessions — the authority that persists after authentication.