authentifizierung

Authentication

Image: Christoph Probst at de.wikipedia, Public domain, Wikimedia Commons

In short: The process in which a user or system proves that it really is the identity it claims to be — e.g. with a password, certificate or biometric feature.

In more detail: Authentication (“who are you?”) is to be distinguished from authorisation (“what are you allowed to do?”) — the two are often confused, but are independent steps: first the identity is checked, then it’s decided on the basis of this identity which rights apply. A session keeps the “already authenticated” state for subsequent requests, so that the user doesn’t have to identify themselves anew for every single action.

In Depth

The classic flow

A typical authentication flow in a web application runs in several steps:

1. User sends credentials (e.g. email + password)
2. Server checks: does the hashed value of the entered password
   match the stored hash? (see Hashing)
3. On success: server creates a session or a signed token (e.g. JWT)
4. Client stores the session cookie/token
5. On every further request: client sends the cookie/token along,
   server checks its validity instead of asking for credentials again

Important: passwords are never stored in plain text on the server, only as a hash (ideally with an additional “salt” that is random per user, to prevent so-called rainbow table attacks, in which an attacker uses pre-computed hash tables for common passwords).

Session-based vs. token-based

There are two fundamentally different architectures for managing the authenticated state. With session-based authentication, the server stores a session state (e.g. in a database or Redis), and the client only holds a random, meaningless session ID as a cookie — the server has to look up with every request whether this ID is valid. With token-based authentication (e.g. JWT, JSON Web Token), the token itself contains all relevant information (user ID, rights, expiry time), cryptographically signed — the server doesn’t have to store anything, it just checks the signature. The advantage of tokens is scalability (no central session store needed, ideal for distributed systems); the drawback: a JWT, once issued, can’t easily be “recalled” before it expires, because the server doesn’t check at all whether it’s still supposed to be valid.

Delegated authentication: OAuth and OpenID Connect

Besides the classic password method, there are increasingly passwordless or delegated approaches: magic links (a one-time link is sent by email), OAuth 2.0/OpenID Connect (authentication is delegated to a third party such as Google or GitHub) and WebAuthn/passkeys (cryptographic key pairs instead of passwords, stored directly on the device). With OAuth/OpenID Connect, the user logs in with the third party, which confirms the identity to your own application with a cryptographic signature — your own application never sees the user’s password, which both reduces your own attack surface and spares the user from having to remember yet another password. These methods avoid the fundamental problem of classic passwords: people often choose weak ones or reuse them across several services — a password leak at service A then also endangers service B.

Typical weaknesses

Common implementation mistakes in authentication: session IDs that are too short or not randomised (guessed/forced), failing to regenerate the session ID after login (session fixation attack, in which an attacker sets a session ID before the victim logs in and afterwards uses the same ID to pose as logged in), and missing rate limiting at login (allows brute-force attacks, in which an attacker automatically tries thousands of passwords). Timing attacks are a more subtle danger: if the server naively compares the entered password character by character with the stored value, an attacker can derive from tiny time differences in the server’s response how many characters have already been guessed correctly — constant-time comparison functions prevent this.

See also: 2FA, Session, Authenticity