Authentication basicsProving identity: factors, passwords, MFA and tokens

Authentication versus authorisation

Two steps that are easy to conflate:

• Authentication proves who you are.
• Authorisation decides what you may do once your identity is known.

You authenticate once when you sign in; the system authorises every subsequent action against your permissions. In HTTP this maps to 401 Unauthorized (authentication missing or failed) versus 403 Forbidden (authenticated but not permitted). The access token that whoami reports is the result of authentication carrying your authorisations.

The three factor types

Multi-factor authentication (MFA) combines two or more different types. Two passwords are not MFA; a password plus a code from your phone is. Requiring different types is what makes a stolen password insufficient.

Passwords, done properly

Passwords are the weakest common factor, but unavoidable. To limit the damage of a breach:

• Never store plaintext. Store a salted hash produced by a deliberately slow function (bcrypt, scrypt, Argon2), so that cracking a leaked database is expensive. Fast hashes (MD5, SHA-1) are unsuitable.
• Salt each password uniquely so identical passwords do not produce identical hashes and precomputed tables are useless.
• Length beats complexity. Long passphrases resist guessing better than short strings of symbols.
• Rate-limit and lock out repeated failures; this is why SSH, RDP and web logins attract brute-force attempts.

Tokens and single sign-on

After you authenticate, systems issue a token (a session cookie, a JWT, a Kerberos ticket) so you do not re-enter credentials for every request. Single sign-on (SSO) extends this across services: you authenticate once with an identity provider, which vouches for you to each application. Windows domains do this with Kerberos over LDAP; the web does it with OAuth and OpenID Connect; network access uses RADIUS.

Tokens must be protected in transit and at rest, because a stolen token can substitute for the credentials that created it. That is one more reason for encryption in transit on every authenticated connection.

Good practice

• Turn on MFA everywhere it is offered, preferring authenticator apps or hardware keys over SMS.
• Use a password manager so every account has a long, unique password.
• Protect the recovery paths (email, phone number); they are authentication too.
• On the server side, hash passwords correctly, rate-limit logins, and prefer phishing-resistant methods (passkeys, security keys) where possible.

Frequently asked questions

What is the difference between authentication and authorisation?

Authentication answers "who are you?" and authorisation answers "what are you allowed to do?". You authenticate once by logging in; the system then authorises each action against your permissions. In HTTP, a 401 means authentication is missing or failed, a 403 means you are authenticated but not permitted.

Why is multi-factor authentication so much stronger?

A password alone can be phished, guessed or leaked in a breach. Adding a second factor of a different type means a stolen password is not enough; the attacker also needs your phone or security key. MFA blocks the large majority of account-takeover attacks.

How should passwords be stored?

Never in plaintext and never with fast hashes like MD5 or SHA-1. Use a slow, salted password-hashing function (bcrypt, scrypt, Argon2) so that even if the database leaks, cracking each password is expensive. See hashing explained.

Sources

• NIST SP 800-63B — Digital Identity Guidelines: Authentication
• CISA — More than a Password (MFA)