The three stages: identification, authentication, authorization

Three taps, six decisions

Sara López wants a $5,000 loan. She opens her bank’s app, types her email and password, enters a code from her phone, picks the loan, confirms with her transaction PIN, and a few seconds later the screen says “Loan approved.” To her it was three taps. Underneath, the bank’s systems answered three different questions and wrote down every answer: who are you claiming to be, can you prove it, and are you allowed to do this?

Those three questions are the stages of every access decision: identification, authentication, and authorization. Next to them runs a fourth piece that isn’t a stage at all but a pillar that crosses all three: audit. In the foundations domain we covered what a digital identity is, the modern identity types, how IAM fits into cybersecurity, the historical waves, the five domains, and the operational cycle. Now we move into the technical heart of access management: how an application decides, on every request, whether an identity may do something or not.

If you separate these pieces cleanly, everything that comes later, MFA factors, authorization models, Zero Trust, session management, falls into place. If you blur them, you’ll confuse yourself, and in a real conversation you’ll confuse the people you’re working with. It’s also a classic interview question for IAM roles: “explain the difference between authentication and authorization in under a minute.” Most people stumble on it. Answering it well, and adding the nuance of identification and audit, makes you stand out.

First, the “3 versus 4 A’s” question

If you’ve read about IAM on your own, you’ve probably met versions that seem to contradict each other. Some books and courses talk about “the 3 A’s”: authentication, authorization, and accounting. Others talk about “the 4 A’s” and add audit. And many list identification, authentication, authorization, and audit side by side as if they were four equivalent stages.

The term AAA comes from RADIUS, the authentication and access control protocol used in enterprise networks since the 1990s, which we met among the veterans. In its original definition, the three A’s are authentication, authorization, and accounting, a record of usage for billing or audit. Identification is implicit inside authentication, because the subject identifies by presenting a credential, and audit is essentially accounting under another name. Some schools separate accounting, the technical record, from audit, the interpretive review of those records, and that’s where “4 A’s” comes from. In practice they’re the same thing with two labels.

In this article and across the program we’ll use a cleaner version: three stages in sequence, identification, then authentication, then authorization, plus one pillar that runs across all of them, audit. They aren’t four steps in a row. Audit doesn’t wait at the end; it works at the same time as the other three, recording every event from the moment the subject says who they are until the action is carried out or blocked.

The whole flow at a glance

Before taking each stage apart, here’s the flow from end to end.

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

The subject comes in from the left and goes through three doors in order. First they state who they are, then they prove it, then the system checks whether they have permission for what they want to do. If all three pass, the action runs; if any fails, it’s refused. Meanwhile audit watches from the side. It doesn’t intervene, but it writes everything down.

Stage 1: Identification

Identification is the subject stating who they are. It’s the first and simplest step, and the one most often confused with authentication. When Sara types sara.lopez@email.com into the sign-in screen, that’s identification. She’s claiming to be the owner of that address. The system doesn’t believe her yet; it has only received her claim. Out of all the possible identities, this is the one she says is hers.

The confusion with authentication comes from the screen. On most sign-in pages both steps happen in one visible interaction: you type the email and the password in the same form, press Enter, and you’re either in or you’re not. It looks like a single step. Conceptually it’s two: identification is the claim (“I’m Sara”), and authentication is the check that the claim is true. At an airport check-in desk you first give your name and then hand over your passport. The name alone won’t get you on the plane.

Identification shows up in many forms. On a classic web sign-in it’s the email or username field. With federated sign-in it’s picking your account from the provider’s list. In an API call carrying a JWT it’s the sub claim inside the token. With a smart card it’s the chip’s serial number, in an SSH connection it’s the username before the @, and on a phone call to the bank it’s the name and customer number you give the operator.

In every case, the identifier is only a label. It proves nothing by itself, which is why it doesn’t need to be secret. An email is public, a username is public, a workload’s name can be public. The strength comes from the next stage, not from hiding the identifier. A common anti-pattern is treating identification as if it were a credential, for example systems that assume knowing a customer number is proof enough. If I know your customer number, I’m not you. An attacker with your identifier can start the flow but should never get past the first door. In 2026, “just enter your card number” as the only check is indefensible.

Stage 2: Authentication

Authentication is checking that the identification claim is true. Sara said “I’m Sara”; now she has to prove it. The proof is one or more factors, pieces of evidence that ideally only the real owner of that identity could produce. The three classic categories are something you know (a password, a PIN, a passphrase), something you have (a phone, a hardware key, a smart card), and something you are (a fingerprint, a face, a voice). Two newer categories are gaining weight: something you do, like a typing rhythm, and something about your context, like location, a known device, or the usual time of day. The next article goes through them in detail.

One factor is single-factor authentication. Two or more from different categories is multi-factor authentication (MFA). A password plus a PIN isn’t MFA, because both are things you know.

The combined flow is always “I claim X,” then “prove you’re X.” The system receives the identification, looks up what it has stored for that identity (password hashes, public keys, registered MFA methods), asks for the matching factors, compares what it received with what it has, and decides. If the identification itself failed because there’s no such user, good practice is to answer with the same generic message as a failed authentication, “invalid username or password,” so an attacker can’t work out which identifiers exist. That detail shows identification sliding into the first step of authentication: visually it’s one block, conceptually it’s two.

Once authenticated, the subject gets a proof of authentication that travels with every later request: a session cookie signed by the server, a token (a JWT or an opaque token) issued by the identity provider, or a SAML assertion in federated setups. That proof isn’t static. It has a limited lifetime and conditions under which it’s revoked, and it has to be checked on every use. Authentication doesn’t end at sign-in; it’s implicitly renewed on every request when the system confirms the token is still valid.

Stage 3: Authorization

Authorization is deciding what an already-authenticated identity may do. Authentication answers “are you really Sara?” Authorization answers “I know you’re Sara, but is this particular thing within your permissions?”

This is the point people most often get wrong: being authenticated doesn’t imply permission for anything in particular. Sara can genuinely be Sara and still not be allowed to run the premium balance report she’s trying to open. Her identity is confirmed; that action isn’t authorized. When a security guard checks your ID at the entrance to an office building, you’ve been authenticated. You haven’t yet been authorized to go up to the seventh floor. That depends on what your visitor pass or staff badge allows.

Each time an authenticated subject tries to do something, the system reads the claims from the token or session (role, scopes, user attributes), reads the policy that applies to the resource (who can read this table, who can approve this payment), and combines the two into a decision: allow or deny. That decision happens on every action, not once. You’re authenticated for hours but authorized on every click.

Formal authorization models are a subject of their own, and later articles cover each one. In short: with DAC the owner of a resource decides who can access it; with MAC the system imposes strict rules, as in military settings; with RBAC permissions are grouped into roles and users receive roles; with ABAC decisions depend on attributes of the subject, the resource, the action, and the context; with PBAC explicit policies are written in a formal language such as OPA’s Rego; and with ReBAC permissions follow from relationships, such as being a member of a team or the owner of a document.

A practical habit when you design an API or an app: ask explicitly where in the code authentication happens and where authorization happens. If the answer is “in the same middleware,” you’re probably mixing them. Keeping them apart makes testing, debugging, and reuse much easier.

The pillar that runs across: audit

Audit doesn’t wait at the end of the flow as one more stage. It works in parallel, recording every event in the other three. Drawing it as a fourth stage suggests it happens after authorization, which is false. It happens at the same time, across everything, which is why the diagram above shows it underneath, connected to each stage by dotted lines: every stage sends records to audit without changing its own flow.

A useful audit record captures who attempted what (the identity and the action requested), when (a timestamp with time zone), from where (IP address, device, location where relevant), the result (success or failure, and if failure, why), and, for operations that change data, what changed, before and after. Successful and failed sign-ins, password changes, requests to access a resource, privileged actions, sign-outs, and configuration changes are all events worth auditing.

It matters for three reasons. Regulations such as SOX, HIPAA, PCI DSS, and GDPR require identity events to be recorded, and without audit you won’t pass an external audit. Threat detection depends on it: ITDR, one of the five domains, lives off audit logs, and without them you can’t spot anomalous behavior. And when an incident happens, the logs are the only way to reconstruct what occurred. A complete, reliable, tamper-proof audit trail is what separates a serious IAM program from an improvised one.

flowchart TB
  accTitle: Audit as a pillar feeding SIEM, ITDR, and Compliance
  accDescr: The three stages, identification, authentication, and 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 form the horizontal production line of access. Audit sits below, receiving events from each stage and feeding three consumers: the SIEM or SOC for general security analysis, ITDR for identity-specific threat detection, and compliance for regulatory reporting.

Back to Sara’s loan

Here’s what happened underneath those three taps.

sequenceDiagram
  accTitle: A mobile banking loan approval across the three stages plus audit
  accDescr: Sara 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 Sara
  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: sign-in 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 (within limit, valid account type)
  M->>App: 5. Transaction PIN (additional factor)
  Lend-->>Aud: Event: loan approved
  Lend->>App: 6. Confirmation

Sara identifies herself with her email and presents her first factor, the password, and the identity provider records the attempt. It asks for a second factor; she enters the code from her phone, and the provider records that MFA succeeded. The provider then issues a signed JWT with the relevant claims (sub=sara.lopez, aal=2, account_type=premium). At this point identification and authentication are complete.

The app calls the loan service with that token. The service extracts the claims and sends them to the authorization engine along with the specific request, a $5,000 loan over 24 months. The engine reads the policy, a maximum of $10,000 a year, premium accounts eligible, customers with more than six months at the bank, and decides to allow it. Because it’s a high-value action, the app asks Sara for her transaction PIN, a step-up authentication on top of the session she already has. Once that arrives, the loan goes through, and the confirmation appears. Audit has recorded the sign-in, the MFA, the authorization decision, the step-up, and the approval.

If anything had failed along the way, a wrong password, a rejected MFA prompt, a policy denying the loan, a wrong PIN, the flow would have stopped and the failure would have been recorded too. That ordered sequence of stages, with the parallel record next to it, is what lets an investigator rebuild any event months later in a few minutes.

Where each stage goes wrong

A lot of application security failures come down to confusing or skipping one of these stages, and each has its usual suspects.

In identification, the classic mistake is treating the identifier as a secret: designing a system on the assumption that knowing a customer number or employee ID is enough to authorize something, when those identifiers leak easily through a breached email, a sticky note, or a phone call. Error messages that reveal whether a user exists (“user not found”) let an attacker enumerate valid accounts; answer with a generic “invalid credentials” instead. And systems that accept an email, a username, or an employee number but treat them internally as three different identities end up with permissions on one that don’t apply to the others.

In authentication, two factors from the same category get mistaken for MFA. Sessions aren’t invalidated when credentials change, even though a password change, especially one prompted by a suspected compromise, should end every active session. The client is trusted to check credentials, with password checks in browser JavaScript or a mobile app deciding on its own that a biometric match was good without confirming with the back end. And long-lived tokens are issued with no way to revoke them, so a leaked token stays live until it expires, sometimes for weeks.

In authorization, the front end does the authorizing. Hiding a “delete” button from non-administrators isn’t authorization; it’s hiding UI. Real authorization always happens on the back end, on every request. Authentication gets confused with authorization, “if you’re signed in, you can go anywhere,” and any authenticated user ends up able to perform administrative actions because nobody checked their specific permissions. Authorization logic is hard-coded and scattered, if user.role == 'admin' sprinkled through the code with no central point, which makes it impossible to audit who can do what and turns every rule change into a deployment. And decisions are based on role alone without context, letting an administrator read any data at any hour from any device, where modern architectures also weigh time, location, and device posture.

In audit, logs that live in the same database as business data can be erased by an attacker with administrator credentials; they belong somewhere the attacker can’t write, such as write-once storage or an external SIEM. Logging the full body of a POST request can leave passwords and tokens in plain text, so deciding what not to log is part of the design. Logs without enough context, “user 12345 did X” with no time zone, IP address, session ID, or request ID, can’t be correlated later. And having all the logs without alerting on critical events, such as promotions to administrator, mass password changes, or privileged access outside working hours, is like installing cameras and switching off the alarm.

Every one of these has caused real, published breaches. When you design or review an application, walking through the three stages and audit with this list in hand takes about twenty minutes and can spare you a very expensive incident.

The three stages side by side

Recap

Every access decision breaks down into three stages in sequence and one pillar that runs across them. Identification is the subject saying who they are; it proves nothing alone and is just a candidate label. Authentication is the subject proving that claim with one or more factors, and its result is a valid session or token. Authorization is the system deciding, for each requested action, whether to allow or deny it based on claims and policies, again and again rather than once. Audit records every event from all three stages in parallel and feeds the SIEM, ITDR, and compliance; it isn’t a fourth stage but a pillar holding up the other three.

The “AAA” name comes from RADIUS and groups authentication, authorization, and accounting. Some materials turn it into “4 A’s” by adding audit, but accounting and audit are the same idea. What matters is understanding what each piece does, not how many A’s are on the list.

Three questions to test yourself

1. After sign-in, a web app keeps only the user’s username and nothing else. Is it authenticating, authorizing, or only identifying? What would the app need in order to authorize later actions correctly?
2. Design the audit for a bank transfer endpoint. Which events would you record, with which fields, and in what order? Keep in mind that an external investigator has to be able to rebuild the whole flow six months later.
3. Your CISO says, “We already have MFA, so we’re protected against unauthorized access.” What’s your counterargument, using what you’ve learned about the three stages?