Authentication

Authentication is the process by which a system checks the identity of whoever is asking for access, whether that is a person, a device or a program. It is done by presenting credentials, and credentials fall into three categories: something you know, something you have and something you are. Using two different categories is two-factor authentication; using two or more, multi-factor.

It answers only the question of who you are. What that identity is then allowed to do is authorisation, decided separately and on every request.

Authentication takes a claim and tests it. A subject presents an identifier and some evidence, and the system decides whether the evidence is good enough to accept the claim. The subject does not have to be a person: services, workloads and agents authenticate constantly, and in most estates those outnumber the humans.

Evidence falls into three categories. Something you know, such as a password or a recovery code. Something you have, such as a hardware key, a device holding a private key, or a phone running an authenticator. Something you are, meaning a biometric measurement. The categories matter because combining two things from the same category adds very little: an attacker who can obtain a password can usually obtain a second password the same way.

Underneath, there are only a few mechanisms. Send a shared secret and compare it, which is what a password does and why the channel has to be protected. Prove possession of a key by signing a challenge, which is what certificates, mutual TLS and passkeys do, and which never transmits the secret at all. Or accept an assertion from a party you trust, which is what federation does with SAML or OpenID Connect.

Once the check passes, the system issues something that stands in for it: a session cookie, a token, a ticket. Almost everything that follows in a real attack is about that artefact rather than about the original check, because stealing the session skips the authentication entirely.

The most productive failure we find is not a weak password. It is a second door. An estate enforces strong authentication on the main path and leaves a legacy protocol, a service account, an API key or a support tool that authenticates a different way, with none of the same conditions applied. On internal and cloud engagements we look for the alternative path before we look at the main one, because the main one has had attention and the alternative one has not.

The second is that authentication is treated as a moment rather than a state. The check happens at login, a session is issued, and nothing revisits it. If the session artefact is stolen, by cross-site scripting, by a phishing proxy, by an infostealer on the endpoint, the attacker never authenticates at all. They arrive already inside. This is why session lifetime and revocation are authentication decisions, even though they happen afterwards.

The third is confusing identification with authentication. A field that says who you are is a claim. We regularly find internal APIs that accept a user identifier in a header and act on it, because the service was written on the assumption that only the gateway could reach it. That assumption is one SSRF away from being wrong.

The fourth is the recovery path. Password reset, account recovery and helpdesk procedures are authentication, and they are usually weaker than the mechanism they can override. An attacker will not attack a hardware key. They will phone the service desk and be issued a temporary credential, which in our social engineering work succeeds more often than any technical route.

These two words are used interchangeably in requirements, in tickets and in vendor documentation, and the confusion produces real vulnerabilities. They are consecutive, separate decisions.

The distinction is not academic. The most common serious API finding we write is that authorisation was checked at the route and not at the object, so a correctly authenticated user can read another customer’s record simply by changing an identifier. Authentication worked perfectly. Nobody asked the second question.

One naming note that catches people out: OAuth 2.0 is an authorisation framework and does not authenticate a user, which is why OpenID Connect exists on top of it. Using a plain OAuth flow as a login mechanism is a recurring design error, and the HTTP header is spelled Authorization in the specification regardless of what the rest of your documentation does.

Counting two factors from the same category. A password plus a security question is one category twice. So is a password plus a memorised PIN.

Enforcing strong authentication only at the front door. Legacy protocols, service accounts, API keys and break-glass accounts all authenticate, and all need a stated position.

Treating the session as out of scope. Lifetime, binding, revocation on privilege change and behaviour on password reset are part of the control, and they are where a compromise is actually survived or not.

Rate limiting the account instead of the source. Lockout on failed attempts is what makes password spraying attractive: an attacker tries one password against thousands of accounts and never trips a per-account counter.

Building your own. Federation, token issuance and credential storage are solved problems with specifications and audited implementations. Every hand-rolled variation we test has at least one finding in it.

Consolidate. Every application that authenticates independently is a separate thing to get right and a separate place to be attacked; federating them to one identity provider means one set of policies, one audit trail and one place to revoke. That consolidation is what makes everything else feasible.

Move the strongest paths to origin-bound factors, which means WebAuthn credentials rather than codes, so that a convincing replica of your login page cannot relay the proof. Where codes are unavoidable, say so explicitly and treat those paths as weaker rather than equivalent.

Bind sessions to something. A token that works from any address, any device and any client is a token worth stealing; conditional policies that re-evaluate device state and location on sensitive operations reduce the value of a stolen one. Re-authenticate before privilege changes, not just at login.

Then fix the recovery path, which is where the real attack lands. Decide who can reset what, require verification that is at least as strong as the factor being replaced, and log it. In estates with a large helpdesk this is usually the highest-value change available.

Authentication is reviewed on almost every engagement, and the finding is written against the specific path, never against the application as a whole: this endpoint, this protocol, this account type. We record what we presented, what was accepted, and what the accepted credential reached afterwards.

The evidence is the request and the response, plus the state we reached with the session it produced. Where we bypassed a factor, we describe the mechanism precisely, because “MFA was bypassed” without a mechanism is not actionable and tends to be read as a product failure when it is usually a policy gap.

Severity follows what the identity reaches, not the elegance of the bypass. Weak authentication on an account with no privileges is an observation. The same weakness on an account that administers the directory is the finding the report is built around.

Identity is where most internal engagements end up, and it is the layer we work through when testing from inside the network.

What is the difference between authentication and authorisation? Authentication establishes who is making the request. Authorisation decides what that subject may do. The first happens once per session; the second has to happen on every request, against every object, and it is where most access control findings come from.

Is MFA the same as strong authentication? Not automatically. Two factors from different categories are better than one, and multi-factor authentication using codes or push approvals can still be relayed by a phishing proxy. Strong means origin-bound, which in practice means WebAuthn.

Does an API key authenticate? It authenticates the holder of the key, which is not the same as authenticating a service. Keys are copied, committed to repositories and shared between environments. Where the platform supports it, short-lived workload credentials are a considerably better answer.

Why do we get a 401 sometimes and a 403 at other times? A 401 means the request was not authenticated, or the credential presented was rejected. A 403 means it was authenticated and the subject is not permitted to do this. Servers get this wrong often enough that the distinction is worth checking rather than assuming.