Authentication

Es gibt drei Wege, zu beweisen, wer du bist (Faktoren):

1. Wissen (Etwas, das du weißt): Passwort, PIN. (Unsicher, weil es gestohlen werden kann).
2. Besitz (Etwas, das du hast): Handy, EC-Karte, YubiKey.
3. Sein (Etwas, das du bist): Fingerabdruck, Gesicht (FaceID), Iris.

Die beste Sicherheit ist eine Kombination: MFA (Multi-Factor Authentication). Also Passwort (Wissen) + Handy-Code (Besitz).

Praxisbeispiel: Ein Login prüft Passwort oder zweiten Faktor. Danach bekommt der Browser eine Session oder ein Token. Mit diesem Nachweis ruft er geschützte Backend-Endpunkte auf.

1. OAuth & OpenID Connect

Wenn du dich irgendwo mit "Login mit Google" anmeldest, passiert im Hintergrund OAuth / OIDC. Die App (z. B. Spotify) sieht dein Google-Passwort nie. Google sagt Spotify nur: "Ja, das ist Max Mustermann, hier ist sein Token." Das ist viel sicherer, als jedem Forum dein Passwort zu geben.

2. Password Hashing

Gute Systeme speichern dein Passwort niemals im Klartext ("geheim123"). Sie speichern einen Hash (Kryptografischen Fingerabdruck), z. B. a3f89.... Wenn Hacker die Datenbank klauen, sehen sie nur den Hash und können das Passwort nicht direkt lesen (außer durch Brute-Force).

Für die Grundlagen dahinter fuehren Passwort, Hashing (Hash Function), Salt (Cryptography) und Brute Force Attack die wichtigsten Sicherheitsbegriffe zusammen.

Technisch muss Authentication Passwörter sicher prüfen, Sessions schützen, Tokens zeitlich begrenzen und Fehlversuche kontrollieren. Die Antwort darf nicht verraten, welcher Teil der Anmeldung falsch war.

1. State vs. Stateless (Session vs. JWT)

Nachdem du bewiesen hast, wer du bist, muss der Server sich das merken.

• Stateful (Session Cookie): Der Server speichert eine ID (z.B. in Redis): Session 123 = Max. Er sendet dir als Cookie (HTTP Cookie) "123". Bei jedem Klick suchst der Server die ID in der Datenbank.
• Stateless (JWT): Der Server signiert krypto-mathematisch ein JSON: {"user": "Max"} und gibt dir dieses JWT. Bei jedem Klick schickst du dem Server das dicke Paket. Der Server prüft nur lokal die Signatur (Mathematik) und weiß ohne Datenbank-Zugriff "Das ist Max!". Perfekt zur Skalierung von Microservices.

2. SAML als Enterprise-Standard

Während öffentliche Apps OAuth2 oder OIDC nutzen, verlangen Großkonzerne oft SAML 2.0 (Security Assertion Markup Language). SAML basiert auf altmodischem, riesigem XML. Wenn du im Firmen-Intranet Confluence öffnest, schiebt Confluence dich sofort zum Identity Provider der Firma (Entra ID, Okta). Nach dem Login wirfst du ein signiertes XML-Paket (die "SAML Assertion") zu Confluence zurück. SAML vertauscht oft die Rollen: Nicht die App greift auf die Identity-API zu, sondern der Client "schleppt" das Zertifikat im Browser zur App.

3. FIDO2 und WebAuthn

Das Ende des Passworts? Die FIDO2-Allianz (Apple, Google, Microsoft) baut Hardware-Keys direkt ins Web. Statt ein Passwort an den Server zu senden, registriert dein Smartphone (Secure Enclave) oder YubiKey mit WebAuthn ein asymmetrisches Schlüsselpaar im Browser. Nur der Public Key liegt auf dem Webserver der Bank. Beim Login sendet die Bank eine kryptografische "Challenge" (Gleichung). Dein Smartphone bittet dich um deinen Fingerabdruck, um den Private Key zu entsperren, rechnet die Challenge aus und sendet die Lösung. Kein Phishing möglich, da niemals ein Passwort über das Internet übertragen wird.