Basic authentication

Basic authentication is the simplest and most fundamental way of verifying somebody’s identity: they present basic credentials, normally a username and a password, and the service compares them with what it has stored.

It rests on the premise that the user can supply something only they know, and it is still what a very large amount of software does by default.

It also carries well-understood risks, because a password can be guessed, phished, reused or intercepted, and none of those failures are visible to the service accepting it.

What characterises it

Username and password. The user supplies an identifier and an associated secret, and the system verifies the pair before allowing or denying access.

The failure modes are known. Phishing, where somebody is tricked into handing the credentials over; brute force, where they are guessed; and credential stuffing, where a password leaked from somewhere else is tried here.

It can be strengthened but not fixed. Strong passwords, sensible policy and user education all help, and none of them change the fundamental property: anybody who obtains the secret becomes the user, with no further obstacle.

A worked example

An email system uses basic authentication to let people reach their accounts.

When somebody signs in, they are asked for their username and password. The pair is sent to the service, which checks it against what it has stored, and if it matches they are given access to the mailbox.

The whole exchange rests on the assumption that only that person knows the password. Everything that goes wrong with basic authentication goes wrong at exactly that assumption, which is why the remedy is not a better password but an additional factor.

Basic authentication, legacy authentication, and authentication in general

There is a name collision here that causes real confusion in Microsoft 365 projects, and it is worth undoing.

Basic authentication, which is what this entry describes, is the scheme: a username and password are sent and the service compares them with what it holds. On the web that is the HTTP Basic scheme, defined in RFC 7617.

Legacy authentication is something else: the family of older mail and client protocols, POP, IMAP and SMTP submission, that accept a password directly and therefore cannot prompt for a second factor or go through conditional access policy. Microsoft also calls this basic authentication, and that is where the confusion comes from.

Why the difference matters: a modern API can use the Basic scheme over TLS and not be legacy authentication at all, while a mailbox with IMAP enabled is legacy authentication even in an organisation that believes multi-factor is switched on everywhere.

And why it is the favourite target of password spraying: one common password tried against every mailbox produces no user prompts and no per-account lockouts, because the attempt is recorded as a protocol event rather than as an interactive sign-in. That asymmetry, cheap for the attacker and quiet for the defender, is the whole reason the technique works.

Authentication on its own is the concept above both, and it answers only who is making the request. What that subject is then allowed to do is authorisation, which is a separate decision.

Where to read more

RFC 7617, The Basic HTTP Authentication Scheme: the IETF specification, including what it does and does not protect.

OWASP, Credential stuffing: how credential reuse turns one breach elsewhere into an incident here, and what mitigates it.