The three stages: identification, authentication, authorization

Welcome to Access Management

In the foundations domain we built a solid base: we know what a digital identity is, the four modern types, how IAM fits into cybersecurity, the four historical waves, the five domains, and what the operational cycle looks like in practice. Now we enter the technical heart of Access Management: how applications decide, on every request, whether an identity may or may not perform an action.

That whole decision breaks down into three sequential stages — identification, authentication, and authorization — plus a transversal pillar that accompanies them: audit. If you separate these pieces well, everything we’ll see later (MFA factors, xBAC models, Zero Trust, session management) falls into place. If you mix them up, you’ll get confused and, worse, confuse your stakeholders in a real conversation.

Before we start: a clarification on “3 vs 4 A’s”

If you’ve researched IAM on your own, you’ve run into two versions that seem to contradict each other:

• Some books and courses talk about “the 3 A’s”: Authentication, Authorization, Accounting.
• Others talk about “the 4 A’s”: Authentication, Authorization, Accounting, and Audit.
• And many materials list identification, authentication, authorization, and audit together as if they were equivalent stages.

Let’s clarify the origin of the term first. AAA comes from the RADIUS standard, an authentication and access control protocol used in enterprise networks since the 90s. In its original definition, the three A’s are:

• Authentication
• Authorization
• Accounting (record of usage for billing or auditing)

Identification stays implicit within authentication (because the subject identifies themselves by presenting their credential), and audit is essentially the same as accounting under a different label. Some schools separate accounting (technical record) from audit (interpretive review of those records), and that’s where “4 A’s” comes from — but in practice they’re the same thing with two names.

For this article and the entire program we’re going to use a clean, grounded version:

• Three sequential stages of the access flow: identification → authentication → authorization.
• One transversal pillar that crosses all of them: audit.

They aren’t four stages in series. Audit doesn’t wait at the end as a fourth step — it operates at the same time as the other three, recording every event from the moment the subject says who they are until the action is executed or blocked.

Big picture: the full flow

Before going deeper into each stage, look at the flow end to end. It’s the movie we’re going to break down next:

flowchart LR
  accTitle: The three stages of an access decision, with audit as a transversal pillar
  accDescr: A subject passes through three sequential stages — identification (who do you say you are), authentication (how do you prove it), and authorization (what can you do) — before the action is executed or denied. Each stage, and the final action, emits records to a transversal audit pillar that runs alongside the flow.
  S([Subject]) --> ID[1. Identification<br/>Who do you say you are?]
  ID --> AUTHN[2. Authentication<br/>How do you prove it?]
  AUTHN --> AUTHZ[3. Authorization<br/>What can you do?]
  AUTHZ --> ACTION[Action executed<br/>or denied]
  AUDIT[(Audit<br/>transversal pillar)]
  ID -.records.-> AUDIT
  AUTHN -.records.-> AUDIT
  AUTHZ -.records.-> AUDIT
  ACTION -.records.-> AUDIT

Reading the diagram: the subject enters from the left. They go through three doors in order — first they declare who they are (identification), then they prove that declaration (authentication), then it’s evaluated whether they have permission for what they want to do (authorization). If they pass all three, the action executes; if any fails, it’s denied. While that happens, audit watches everything from the side, without intervening, but recording.

Stage 1: Identification

What it is exactly

Identification is the subject declaring who they are. It’s the first step, the simplest, and also the one most often confused with authentication.

When you type your email on a login screen, that’s identification. You’re claiming “I’m the owner of maria@company.com.” The system doesn’t believe you yet, it just receives your claim. It’s a classification question: out of the universe of possible identities, which one do you say you are?

Why it gets confused with authentication

Many people — including experienced developers — use “identify” and “authenticate” as synonyms. The reason is that in many login screens both steps happen in a single visible interaction: you type the email and the password in the same form, hit Enter, and you’re either in or you aren’t. It looks like one step.

But conceptually they are two different things:

• Identification = claim: “I say I’m María.”
• Authentication = verification: the system checks that the claim is true.

A useful analogy: when you arrive at an airport for check-in, you first give the agent your name (identification) and then hand them your passport (authentication). The name alone doesn’t let you fly — you need the proof.

Concrete examples

What it does well and what it doesn’t do

Identification is just a label. It proves nothing on its own. That’s why an identity shouldn’t be secret — an email is public, a username is public, a machine identity can be public. Strength comes from the next step (authentication), not from keeping the identifier hidden.

A very common anti-pattern is treating identification as if it were a credential. For example, systems that assume knowing a customer number is enough proof of identity. That’s a serious mistake: if I know your customer number, I’m not you. An attacker with your identifier can start the flow, but should not be able to get past the first stage.

Stage 2: Authentication

What it is

Authentication is the verification that the identification claim is true. If in stage 1 you said “I’m María,” in stage 2 you have to prove it. The proof consists of presenting one or more factors — pieces of evidence that, ideally, only the true owner of that identity could have.

Factors fall into three classic categories (which we’ll cover in detail in the next article):

• Something you know — password, PIN, passphrase.
• Something you have — phone, hardware key, smart card.
• Something you are — fingerprint, face, voice.

To these we add two modern categories that are gaining weight:

• Something you do — typing pattern, gestures.
• Something about your context — geolocation, known device, usual time.

If you present one factor, it’s single-factor authentication (SFA). If you present two or more from different categories, it’s multi-factor authentication (MFA). Asking for password + PIN is not MFA — both are things you know.

How it complements identification

The combined flow is always: “I claim X” → “prove you’re X.” The system:

1. Receives the identification.
2. Looks up in its store the information associated with that identity (password hashes, public keys, registered MFA methods).
3. Asks the subject for the corresponding factors.
4. Compares what was received with what’s stored.
5. Decides: authenticated or not.

If identification failed (no such user), a good practice is to respond with the same generic message as when authentication fails (“invalid username or password”) — to prevent an attacker from enumerating valid identifiers. Note how identification slips into that first step, before authentication: in most UIs they’re visually a single block, but conceptually they’re two different things.

Result of authentication

Once authenticated, the subject receives a proof of authentication that will travel with every subsequent request. That proof can be:

• A session cookie signed by the server.
• A token (JWT, opaque token) issued by the IdP.
• A SAML assertion for federated cases.

What matters is that this proof is not static — it has limited lifetime, revocation conditions, and must be verified on every use. Authentication doesn’t end at login; it “renews” implicitly on every request when the system validates that the token is still valid.

Stage 3: Authorization

What it is and why it’s different from authentication

Authorization is the decision of what an already-authenticated identity can do. If authentication answers “are you really María?”, authorization answers “I already know you’re María, but is this thing you want to do within your permissions?”.

Here’s a point many confuse: being authenticated doesn’t imply permission for anything in particular. María can legitimately be María, and still not have access to the premium account balance query she’s trying to execute. Her identity is confirmed; her action isn’t authorized.

A way to fix it: when a guard verifies your official ID at the entrance of a building, they authenticated you. But they haven’t yet authorized you to enter the 7th floor — that depends on what your visitor pass or corporate credential says.

How it works in practice

Each time the authenticated subject attempts an action, the system:

1. Reads the claims from the token or session (role, scopes, user attributes).
2. Reads the policy applicable to the resource (who can read this table? who can approve this payment?).
3. Combines both and decides: allow or deny.

That decision happens on every action, not just once. You’re authenticated for hours, but authorized on every click.

Authorization models (preview)

Formal authorization models are a topic of their own. Here’s a preview:

For now it’s enough to know that authorization materializes in one or more of these models; a dedicated article goes into the detail.

The transversal pillar: audit

Why it’s not a fourth stage

Audit doesn’t wait at the end of the flow as one more stage. It works in parallel, recording every event that occurs in the other three. If we paint it as a fourth stage, we suggest it happens after authorizing — and that’s false. It happens at the same time, crossing through everything.

That’s why in the diagram at the start it appears below, connected with dotted arrows to the three stages: each one emits records to audit without altering its main flow.

What audit records

A useful audit captures, for each event:

• Who attempted what (identity + requested action).
• When they attempted it (timestamp with time zone).
• From where they attempted it (IP, device, geolocation when applicable).
• Result (success or failure, and if failure, why).
• What changed (if it was an operation that modified data, the before and after).

Examples of auditable events: a successful or failed login, a password change, a resource access request, a privileged action executed, a logout, a configuration modification.

Why it matters

Three main reasons:

1. Regulatory compliance: SOX, HIPAA, PCI-DSS, GDPR require recording identity events. Without audit you don’t pass external audits.
2. Threat detection: ITDR (one of the five domains) lives off audit logs. Without those logs, you can’t detect anomalous behavior.
3. Forensics: when an incident happens, the logs are the only way to reconstruct what happened. Without them, you fly blind.

A complete, reliable, and immutable audit is what differentiates a serious IAM program from an improvised one.

Audit feeds the rest of the security stack

flowchart TB
  accTitle: Audit as a pillar feeding SIEM, ITDR, and Compliance
  accDescr: The three stages — identification, authentication, authorization — run as a horizontal sequence. A transversal audit component receives events from that flow and in turn feeds three consumers: a SIEM or SOC, an ITDR system, and Compliance reporting.
  subgraph Flow["Access flow"]
    direction LR
    ID[1. Identification] --> AUTHN[2. Authentication]
    AUTHN --> AUTHZ[3. Authorization]
  end
  AUDIT[Audit<br/>records everything, all the time]
  Flow -.events.-> AUDIT
  AUDIT -.feeds.-> SIEM[(SIEM / SOC)]
  AUDIT -.feeds.-> ITDR[ITDR]
  AUDIT -.feeds.-> COMP[Compliance]

The three stages live in a horizontal sequence — the access “production line.” Audit is below, receiving events from each stage, and in turn feeding three consumers: SIEM/SOC for general security analysis, ITDR for specific identity threat detection, and Compliance for regulatory reports.

Integrated case: a mobile banking operation

To anchor everything above in a recognizable case, let’s follow María trying to approve a $5,000 loan from her bank’s mobile app.

What’s seen on screen

1. María opens the app and the “Sign in” screen appears.
2. She types maria.garcia@email.com and her password, presses “Enter.”
3. The app asks her for a code from her mobile token. María types it.
4. She enters the dashboard. Selects “Loans.” Picks one for $5,000 over 24 months.
5. The app asks for her transaction PIN (an extra security step).
6. “Loan approved” appears.

Three visible steps. But there are six logical steps happening underneath:

What happens underneath

sequenceDiagram
  accTitle: A mobile banking loan approval across the three stages plus audit
  accDescr: María authenticates to a banking app with email, password, and an MFA code; the bank's IdP issues a signed JWT; the loan service asks an authorization engine whether she may borrow 5000 dollars; after a step-up transaction PIN the loan is approved. The IdP, engine, and loan service emit login, MFA, authorization-decision, and loan-approved events to audit.
  actor M as María
  participant App as Banking app
  participant IdP as Bank's IdP
  participant Eng as Authorization engine
  participant Lend as Loan service
  participant Aud as Audit
  M->>App: 1. Email + password (identification + factor 1)
  App->>IdP: Verifies identity
  IdP-->>Aud: Event: login attempt
  M->>App: 2. MFA code (factor 2)
  IdP-->>Aud: Event: MFA verified
  IdP->>App: 3. JWT with signed claims
  App->>Lend: 4. POST /loan/apply (Bearer JWT)
  Lend->>Eng: Is she authorized?
  Eng-->>Aud: Event: authorization decision
  Eng->>Lend: Allowed (limit not exceeded, valid account type)
  M->>App: 5. Transaction PIN (additional factor)
  Lend-->>Aud: Event: loan approved
  Lend->>App: 6. Confirmation

Step-by-step reading, mapped to the three stages + audit:

• Step 1: María identifies herself with her email and presents the first factor (password). The IdP validates and records the attempt in audit.
• Step 2: The IdP requests a second factor; María provides it. It’s recorded that MFA was verified.
• Step 3: The IdP issues a signed JWT with the relevant claims (sub=maria.garcia, aal=2, account_type=premium). Up to here: identification + authentication complete.
• Step 4: The app calls the loan service API with the token. The service extracts the claims and sends them to the authorization engine along with the specific request (“apply for a $5,000 loan, 24 months”).
• Authorization decision: the engine evaluates whether María, with her account type and her attributes, can request this loan. It reads the policy — max $10,000 per year, premium account enabled, customer with more than 6 months tenure — and decides: allow.
• Step 5: The app asks María for her transaction PIN (an additional factor, step-up authentication, for high-value actions). Once received, the operation executes.
• Step 6: María is confirmed. Audit has recorded all events: login, MFA, authorization decision, step-up, loan approved.

If at any point something had failed — wrong password, MFA not approved, policy denying the loan, wrong PIN — the flow would stop and the failure would be recorded in audit. That ordered sequence of stages + the parallel record is what allows, later, an investigator to reconstruct any event in minutes.

Common mistakes per stage (anti-patterns)

A lot of what goes wrong in application security boils down to confusing or skipping one of the three stages. It’s worth knowing the most common mistakes so you don’t repeat them:

Mistakes in identification

• Treating the identifier as a secret. Designing a system assuming that knowing the customer number or employee ID is enough to authorize actions. Those identifiers are easily obtainable (a leaked email, a sticky note on the desk, social engineering).
• Messages that leak whether a user exists. Showing “user does not exist” on a login screen lets an attacker enumerate valid identities. Best practice is to respond generically with “invalid credentials” without distinguishing whether identification or authentication failed.
• Allowing multiple identifiers without coherence. Some systems let you log in with email OR username OR employee number, but internally treat them as three different identities. Result: permissions assigned to one identifier don’t apply to the other.

Mistakes in authentication

• Considering two factors of the same category as MFA. Asking for password + PIN is not MFA; they’re both things you know. For genuine MFA, the factors must be from different categories.
• Not invalidating sessions when credentials change. When a user changes their password, all their active sessions should be invalidated — especially if the change was due to suspected compromise. Many systems don’t.
• Trusting the client to validate credentials. Doing password verification in browser JavaScript, or letting the mobile app decide if biometric was valid without backend confirmation.
• Not having a token revocation mechanism. Issuing long-lived tokens with no way to invalidate them. If a token leaks, it stays active until natural expiration — that can be weeks.

Mistakes in authorization

• Authorizing only on the frontend. Hiding a “delete” button if the user isn’t admin is not authorizing — it’s hiding UI. Real authorization always happens in the backend, validating every request.
• Confusing authentication with authorization. The “if logged in, let them in everywhere” mistake. Result: any authenticated user can execute administrative actions because nobody checked their specific permissions.
• Hardcoding authorization logic scattered through code. Rules like if user.role == 'admin' sprinkled throughout the app, with no central point. Impossible to audit who can do what, and modifying rules requires a deploy.
• Authorization based only on role without context. Allowing an admin to read any data at any time from any device. Modern architectures (Zero Trust) also evaluate contextual attributes: time, location, device posture.

Mistakes in audit

• Non-immutable logs. If logs live in the same database as business data, an attacker with admin credentials can erase their tracks. Logs should go to a destination where the attacker can’t write (write-once storage, external SIEM).
• Logging credentials by accident. Logging the full body of a POST request can leave passwords and tokens in plain text inside the log. Sanitizing what’s logged is part of the design.
• Logs without enough context to reconstruct. Logging “user 12345 did action X” without timestamp with TZ, without IP, without session ID, without request ID. Impossible for an investigator to correlate later.
• Not alerting on critical events. Having all the logs but not monitoring sensitive changes (admin promotions, mass password changes, privileged access outside business hours). It’s like having cameras but turning off the alarms.

Summary table: the three stages compared

Recap

The flow of every access decision breaks down into three sequential stages and a transversal pillar:

• Identification — the subject says who they are. Doesn’t prove anything on its own; just a candidate label.
• Authentication — the subject proves that claim with one or more factors. Result: a valid session or token.
• Authorization — for each requested action, the system decides allow or deny based on claims and policies. Evaluated again and again, not just at the start.
• Audit — records every event of the three stages in parallel, feeding SIEM, ITDR, and Compliance. It’s not a fourth stage; it’s a pillar that supports all three.

The “AAA” nomenclature (3 A’s) comes from the RADIUS standard and groups Authentication, Authorization, Accounting. Some materials rewrite this as “4 A’s” by adding Audit, but accounting and audit are conceptually the same thing. What matters is that you understand the function of each one, not how many A’s you have on your list.

Three questions to test yourself

1. A web app gives you only the user’s username after login, with no other information. Is it authenticating, authorizing, or just identifying? What would the app need to do to correctly authorize subsequent actions?
2. Design the audit for a banking transfer endpoint. What events do you record, with what fields, and in what order? Consider that an external investigator must be able to reconstruct the full flow six months later.
3. Your CISO says “we already have MFA, we’re protected against unauthorized access.” What’s your counterargument using what you learned about the three stages?