Authentifizierung

Wer bist du?

Nicht jede Zwei-Faktor-Lösung ist gleich gut. SMS-Codes lassen sich durch das Umleiten der Telefonnummer abfangen (SIM-Swapping). Einmalcodes aus einer App (TOTP: aus einem gemeinsamen Geheimnis und der Uhrzeit berechnet, alle 30 Sekunden neu) sind besser – aber ein Nutzer kann sie auf einer Phishing-Seite eintippen. Wirklich phishing-resistent sind nur Hardware-Schlüssel und Passkeys.

Passwörter speichern

Die Grundregel: Ein Server speichert nie das Passwort selbst, sondern einen Hash. Beim Login wird die Eingabe gehasht und verglichen. Aber welcher Hash? Was passiert, wenn die Datenbank gestohlen wird – und das passiert ständig – zeigt das Experiment:

Drei Lehren daraus:

• Salt: Ein zufälliger Wert pro Nutzer, der mitgehasht und neben dem Hash gespeichert wird. Gleiche Passwörter ergeben dann verschiedene Hashes, und vorberechnete Tabellen werden nutzlos. Der Angreifer muss jedes Konto einzeln angreifen.
• Langsam ist gut: SHA-256 ist für Geschwindigkeit gebaut – genau das Falsche für Passwörter. bcrypt, scrypt, PBKDF2 und Argon2id sind absichtlich teuer, mit einstellbarem Aufwand. Argon2id braucht zusätzlich viel Speicher pro Versuch, was Grafikkarten ausbremst. Für einen Nutzer ist ein Login von 100 Millisekunden unmerklich – für einen Angreifer ist es das Ende.
• Länge schlägt Komplexität: Die aktuelle NIST-Empfehlung verlangt lange Passwörter statt Sonderzeichen-Regeln, verzichtet auf erzwungene regelmäßige Wechsel und prüft neue Passwörter gegen Listen bereits geleakter Passwörter.

Nach dem Login: Sitzung oder Token

HTTP ist zustandslos – der Server muss den Nutzer bei jeder Anfrage wiedererkennen. Zwei Wege:

Weil Tokens nicht zurückgerufen werden können, gibt man ihnen eine kurze Laufzeit – Minuten – und dazu ein langlebiges Refresh-Token, mit dem der Client sich neue holt. Das Refresh-Token kann der Server sperren.

Was in einem JWT steht

Ein JSON Web Token besteht aus drei Base64-kodierten Teilen, getrennt durch Punkte: Kopf, Inhalt, Signatur. Der Inhalt ist nicht verschlüsselt – jeder kann ihn lesen. Geschützt ist er nur gegen Veränderung:

OAuth 2 und OpenID Connect

„Anmelden mit Google“, „Diese App möchte auf deinen Kalender zugreifen“ – dahinter steckt OAuth 2. Sein Zweck ist delegierter Zugriff: Eine Anwendung bekommt eingeschränkte Rechte, ohne je das Passwort zu sehen. Früher gab man Drittanbietern sein Passwort – und damit alles. OpenID Connect (OIDC) setzt darauf auf und liefert zusätzlich ein ID-Token, das sagt, wer sich angemeldet hat. Erst damit wird OAuth zum Login.

Wichtige Begriffe auf einen Blick: Der Scope legt fest, was die App darf – etwa nur Kalender lesen. Das Access-Token öffnet die API, das ID-Token sagt der App, wer der Nutzer ist, das Refresh-Token holt neue Access-Tokens. Bekannte Autorisierungsserver sind Keycloak, Microsoft Entra ID, Okta, Auth0 sowie Google und Apple für Endkunden.

Passkeys: Anmelden ohne Passwort

Passkeys (technisch: WebAuthn und FIDO2) ersetzen das Passwort durch ein Schlüsselpaar, wie in der Kryptografie beschrieben. Bei der Registrierung erzeugt das Gerät für genau diese Website ein Paar; der Server bekommt nur den öffentlichen Schlüssel. Beim Login schickt der Server eine Zufallszahl, das Gerät signiert sie mit dem privaten Schlüssel – freigegeben per Fingerabdruck, Gesicht oder PIN.

Für Entwickler übersetzt

// Passwörter: Spring Security
PasswordEncoder enc = PasswordEncoderFactories.createDelegatingPasswordEncoder();
String gespeichert = enc.encode("sommer2026");   // "{bcrypt}$2a$10$Xk9…" – Verfahren, Kosten, Salt, Hash
boolean ok = enc.matches(eingabe, gespeichert);

// API als OAuth-Resource-Server: Tokens prüft Spring anhand des Ausstellers
// application.yml:
//   spring.security.oauth2.resourceserver.jwt.issuer-uri: https://login.example.com/realms/shop

@GetMapping("/api/bestellungen")
@PreAuthorize("hasAuthority('SCOPE_bestellungen.lesen')")
List<Bestellung> meine(@AuthenticationPrincipal Jwt jwt) {
    return service.fuerKunde(jwt.getSubject());
}

Häufige Irrtümer

Verwandte Begriffe