Authentication Protocol
Ein Authentication Protocol (deutsch: Authentifizierungsprotokoll) ist ein Kommunikations- bzw. kryptografisches Protokoll, das den sicheren Austausch von Anmeldedaten zwischen zwei oder mehr Parteien beschreibt. Es dient dazu, Identitäten zuverlässig zu prüfen, optional beidseitig zwischen Client und Server, und erschwert dabei Angriffe wie Replay oder Phishing. In der Praxis umfasst ein Authentication Protocol klar definierte Nachrichtenfolgen, kryptografische Prüfungen und oft die Bindung an eine Sitzung [Q1][Q3].
Hintergrund und Entstehung
Authentication Protocols entstanden, um Identitäten auch in unsicheren Netzen nachprüfbar zu machen. Früh kam dafür Challenge-Response zum Einsatz. Später kamen ticketbasierte Verfahren wie Kerberos hinzu, das heute in RFC 4120 spezifiziert ist und Single Sign-on in Unternehmensnetzen ermöglicht [Q3].
Mit der zunehmenden Nutzung des Webs und verteilten Diensten wurde Föderation wichtig: Protokolle wie SAML 2.0 und OpenID Connect (OIDC) erlauben, dass ein Identity Provider das Ergebnis der Authentifizierung an eine Anwendung übermittelt. OIDC baut dabei auf dem Autorisierungs-Framework OAuth 2.0 auf [Q1][Q3].
Regulatorisch haben sich Reifegradmodelle etabliert. NIST SP 800-63B definiert Authentifizierungs-Anforderungsniveaus (AAL1–AAL3) und beschreibt geeignete Faktoren und Protokolldesigns. Im DACH-Kontext empfiehlt das BSI den Einsatz starker bzw. mehrstufiger Authentisierung und beschreibt Anforderungen an Identifizierung und Authentisierung in technischen Richtlinien [Q1][Q2].
Wichtigste Merkmale und Kernelemente
Zielgerichtete Identitätsprüfung
Ein Authentication Protocol definiert Rollen (z. B. Antragsteller, Prüfer, ggf. Aussteller) und Schritte, um eine behauptete Identität kryptografisch zu belegen. Dazu gehören Nicht-Wiederverwendbarkeit (Nonces), Frische und ggf. die Bindung an Sitzungs- oder Transport-Schlüssel [Q1].
Gegenseitige Authentisierung und Schlüsselaushandlung
Viele Protokolle kombinieren Identitätsprüfung mit dem Aufbau eines vertraulichen Kanals. TLS 1.3 unterstützt neben serverseitiger auch clientseitige Zertifikatsauthentisierung. Schlüsselmaterial wird während des Handshakes abgeleitet [Q3].
Beispiele (klassisch bis modern)
Ticketbasiert (Kerberos), passwortauthentisierte Schlüsselaushandlung (SRP/TLS-SRP), transportgebunden (EAP-TLS im WLAN), föderiert (SAML 2.0, OpenID Connect für Web-SSO) sowie phishing-resistente Verfahren wie WebAuthn/FIDO2 mit öffentlichen Schlüsseln [Q1][Q3].
Abgrenzung zu Autorisierung
OAuth 2.0 ist ein Autorisierungs-Framework. Es regelt die Erteilung von Zugriffsrechten (Tokens), nicht die Feststellung der Identität. OpenID Connect ergänzt genau diese Identitätsschicht über OAuth 2.0 [Q1][Q3].
Bedeutung für Unternehmen und Praxisrelevanz
Für Unternehmen im DACH-Raum ist die richtige Wahl des Authentication Protocols entscheidend für Sicherheit, Compliance und Nutzerakzeptanz. Starke Authentisierung mit geeigneten Faktoren und Protokollen reduziert Account-Übernahmen und erfüllt Anforderungen vieler Branchenstandards [Q1][Q2].
In verteilten Anwendungslandschaften erleichtert Föderation (SAML 2.0, OIDC) Single Sign-on über Unternehmens- und Cloud-Dienste hinweg. Damit sinkt die Passwortlast und Zugriffsentscheidungen lassen sich zentralisieren. Für besonders schutzbedürftige Prozesse empfiehlt sich eine Step-up-Authentisierung (z. B. WebAuthn) [Q1].
Auch auf der Transportschicht steigert korrekte Protokollnutzung die Sicherheit: TLS 1.3 mit optionaler Client-Zertifikatsprüfung oder EAP-Methoden in WLAN/VPN bieten kryptografisch gebundene Identitäten und verhindern viele Man-in-the-Middle-Angriffe [Q3].
Abgrenzung zu verwandten Begriffen
Authentication Protocol vs. Authorization Protocol
Ein Authentication Protocol prüft, wer jemand ist. Ein Authorization-Protokoll bzw. -Framework (z. B. OAuth 2.0) regelt, welche Rechte nach erfolgreicher Authentisierung gelten. OIDC ergänzt OAuth um eine standardisierte Identitäts-Assertion [Q1].
Authentication Protocol vs. Transportverschlüsselung
TLS stellt einen geschützten Kanal bereit. Die eigentliche Identitätsprüfung kann innerhalb des Handshakes (z. B. Client-Zertifikate) oder darüberliegend (z. B. OIDC im Browser) erfolgen [Q3].
Beispiele aus der Praxis
Beispiel 1: Web-SSO im Konzern (ca. 5.000 MA)
Ein Unternehmen migriert Applikationen in die Cloud. Über OpenID Connect mit zentralem Identity Provider wird SSO eingeführt, MFA per WebAuthn für kritische Anwendungen aktiviert. Ergebnis: 40 % weniger Passwort-Tickets und ein Rückgang von erfolgreichen Phishing-Angriffen [Q1].
Beispiel 2: WLAN-Zugang mit Geräte-Identität
Für das Büro-WLAN setzt ein Betreiber EAP-TLS ein. Geräte werden mit Zertifikaten verwaltet. Nur verwaltete Endgeräte erhalten Netzwerkzugang. Angriffe durch abgefangene Passwörter werden wirkungslos [Q2][Q3].
Quellen
[Q1] NIST SP 800-63B: Digital Identity Guidelines – Authentication and Lifecycle Management, https://pages.nist.gov/800-63-3/sp800-63b.html, Abrufdatum: 06.11.2025.
[Q2] BSI: Multi-Faktor-Authentisierung – Einfach erklärt und empfohlen, https://www.bsi.bund.de/DE/Themen/Verbraucherinnen-und-Verbraucher/Informationen-und-Empfehlungen/Cyber-Sicherheitsempfehlungen/Accountschutz/Zwei-Faktor-Authentisierung/zwei-faktor-authentisierung_node.html, Abrufdatum: 06.11.2025.
[Q3] Wikipedia: Authentication protocol, https://en.wikipedia.org/wiki/Authentication_protocol, Abrufdatum: 06.11.2025.