Nur die OpenSSL 3.
Die Komponente TsgcWSAPIServer_WebAuthn bietet eine einfache, aber leistungsstarke Lösung zur Implementierung des WebAuthn-Relying-Party-Servers und ermöglicht passwortlose Authentifizierung in Ihrer Webanwendung. Eine WebAuthn-Anwendung besteht aus einem WebAuthn-Server, der die serverseitige Registrierung und Authentifizierung verarbeitet, und einer clientseitigen Anwendung, die normalerweise eine JavaScript-Anwendung ist.
WebAuthn erfordert die Verwendung sicherer Verbindungen (SSL/TLS), daher müssen die OpenSSL-Bibliotheken bereitgestellt und mit dem Server konfiguriert werden.
Nur die OpenSSL-3.0.0+-API wird unterstützt, daher funktionieren frühere OpenSSL-Versionen möglicherweise nicht.
Konfiguration
Der TsgcWSAPIServer_WebAuthn muss über die Eigenschaft Server an einen HTTP-Server angehängt werden, TsgcWebSocketHTTP_Server oder TsgcWebSocketServer_HTTPAPI. Sie können die Server-Endpunkte konfigurieren, die die Registrierungs- und Authentifizierungsoptionen behandeln, sowie die WebAuthn-Optionen wie unterstützte Algorithmen, Origins und mehr.
Endpoints-Optionen
Hier können Sie die Server-Endpunkte konfigurieren, die die HTTP-/JavaScript-Anfragen zur Verwendung von WebAuthn als Authenticator behandeln. Die Komponente ist bereits mit Standard-Endpunkten konfiguriert, aber Sie können alle von ihnen an Ihre Bedürfnisse anpassen.
- AuthenticationOptions: standardmäßig /sgcWebAuthn/Authentication/Options
- AuthenticationVerify: standardmäßig /sgcWebAuthn/Authentication/Verify
- RegistrationOptions: standardmäßig /sgcWebAuthn/Registration/Options
- RegistrationVerify: standardmäßig /sgcWebAuthn/Registration/Verify
- Webauthn: enthält die standardmäßig verwendete JavaScript-Bibliothek. Sie können diese Eigenschaft deaktivieren und Ihre eigene WebAuthn-Bibliothek verwenden.
- Test: standardmäßig deaktiviert, nur zum Testen der WebAuthn-Funktionalität verwenden.
Beispiel: wenn Ihr Server auf der Domain www.test.com lauscht, ist die Anforderung an die Authentifizierungsoptionen standardmäßig http://www.test.com/sgcWebAuthn/Authentication/Options
WebAuthn Options
In dieser Eigenschaft können Sie die Hauptoptionen der WebAuthn-Server-Komponente konfigurieren.
- RelyingParty: eine obligatorische Eigenschaft, in der der DNS-Name des Servers definiert werden muss. Beispiel: Wenn der Server auf der Domäne www.test.com läuft, setzen Sie diese Eigenschaft auf "www.test.com".
WebAuthn verwendet Origins, um Same-Origin-Policy-Einschränkungen durchzusetzen, die für die Verhinderung von Phishing- und Cross-Site-Angriffen unerlässlich sind. Während der WebAuthn-Registrierungs- und Authentifizierungsprozesse wird der Origin vom Browser und vom Authenticator streng validiert.
- Origins: Wenn die Anfragen von verschiedenen Origins kommen können, verwenden Sie die Eigenschaft Origin, um die zusätzlichen Origins festzulegen. Beispiel: wenn die Anfragen von login.test.com und www.test.co.uk kommen können, konfigurieren Sie die Eigenschaft Origins mit den Werten: https://login.test.com und https://www.test.co.uk
- TopOrigins: Normalerweise verlässt sich WebAuthn auf den Origin des aufrufenden Frames (d. h. desjenigen, der navigator.credentials.create() oder navigator.credentials.get() aufruft). Webseiten können jedoch in iframes eingebettet sein, die von einem anderen Origin als die Top-Level-Seite stammen können. Dies eröffnet Potenzial für Missbrauch oder Clickjacking-artige Angriffe. Um dies zu mindern, führt die WebAuthn-Level-2-Spezifikation TopOrigin ein, wo Sie die TopOrigins definieren können.
In WebAuthn ist crossOrigin ein boolescher Parameter, der angibt, ob die WebAuthn-Operation aus einem cross-origin Kontext heraus durchgeführt wird, wie zum Beispiel einem iframe, das aus einem anderen Origin als der Top-Level-Browsing-Kontext eingebettet ist.
Dieser Parameter wurde eingeführt, um Browsern und Authenticatoren zu helfen, Authentifizierungsanfragen in eingebetteten Umgebungen sicher zu verarbeiten — ein häufiges Szenario in modernen Webanwendungen.
- AllowCrossOrigins: falls true, gibt an, dass Anfragen aus einem Cross-Origin-iframe (z. B. einem iframe unter https://auth.example.com, das in eine Seite unter https://app.example.org eingebettet ist) zulässig sind. Standardmäßig ist dies deaktiviert.
WebAuthn unterstützt eine Vielzahl von kryptografischen Algorithmen für die Generierung und Verifizierung von Public-Key-Anmeldedaten. Diese Algorithmen werden während der Registrierung von Anmeldedaten (mit navigator.credentials.create()) und der Authentifizierung (mit navigator.credentials.get()) verwendet und gewährleisten das sichere Signieren und Validieren von Challenges mithilfe asymmetrischer Schlüsselpaare. Der Server ist standardmäßig mit ES256 und RS256 konfiguriert, die die häufigsten Algorithmen sind. Sie können jederzeit über die Eigenschaft Algorithms ändern, welche Algorithmen unterstützt werden. Die folgenden Algorithmen werden unterstützt:
- ES256
- ES384
- ES512
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- RS1
- EdDSA
In WebAuthn ist Attestierung ein optionaler Mechanismus, der es dem Authenticator (z. B. Gerät oder Sicherheitsschlüssel) ermöglicht, während der Erstellung von Anmeldedaten Informationen über seinen Hersteller, sein Modell und seine Sicherheitsmerkmale bereitzustellen. Diese Informationen helfen der Relying Party (RP) zu entscheiden, ob sie dem Authenticator vertrauen soll.
Verschiedene Attestierungsformate definieren, wie diese Daten strukturiert und verifiziert werden. Drei häufig verwendete Formate sind android-key, packed und andere wie fido-u2f, apple oder none. Standardmäßig sind alle Attestierungsformate aktiviert. Unten finden Sie die Liste der unterstützten Attestierungsformate:
- NoneAttestation: in diesem Fall werden keine Attestation-Daten zurückgegeben. Priorisiert die Privatsphäre der Benutzer, indem die Offenlegung von Gerätebezeichnern vermieden wird. Üblich in Anwendungen, die sich nicht um die Geräteherkunft kümmern.
- PackedAttestation: ist ein flexibles, kompaktes Format, das von vielen Authenticatoren verwendet wird. Der Authenticator gibt ein Attestationszertifikat und eine Signatur zurück. Kann sein: Full Attestation: signiert mit einem vom Hersteller bereitgestellten Schlüssel und Zertifikat, oder Self Attestation: signiert mit dem privaten Schlüssel des Credentials. Am weitesten verbreitet über verschiedene Plattformen (z. B. YubiKey, Windows Hello).
- TPMAttestation: Wird von Geräten mit einem Trusted Platform Module (TPM) verwendet. Die Attestation wird mit Schlüsseln aus dem TPM signiert und enthält eine Zertifikatskette. Wird von Enterprise-Desktops/-Laptops mit TPM-Chips verwendet (z. B. Windows-Computer).
- AndroidKeyAttestation: Wird von Android-Geräten mit dem Android Keystore verwendet. Der Schlüssel wird in Hardware generiert, und die Attestierung umfasst Informationen, die von einer vom Gerätehersteller ausgestellten Zertifikatkette signiert sind. Wird von Android-Telefonen mit hardwaregestützten Keystores (TEE oder StrongBox) verwendet.
- AppleAttestation: Wird von Apple-Plattform-Authenticatoren wie Touch ID und Face ID verwendet. Die Attestation wird von Apples internen APIs generiert und enthält ein spezielles Zertifikatsformat. Wird in Safari mit Apple-Biometrie verwendet.
- FidoU2FAttestation: Veraltetes Attestierungsformat, das von FIDO-U2F-Authenticatoren verwendet wird. Gibt ein U2F-kompatibles Zertifikat und eine Signatur zurück. Wird von älteren Sicherheitsschlüsseln verwendet (z. B. frühe YubiKeys), die FIDO U2F unterstützen.
In der WebAuthn-API ist AllowCredentials ein optionales Feld, das während des Authentifizierungsvorgangs (über navigator.credentials.get()) verwendet wird. Es gibt eine Liste von Credential-IDs an, die berechtigt sind, den Benutzer zu authentifizieren für eine bestimmte Relying Party (RP). Dieser Mechanismus ermöglicht es der RP zu steuern, welche Credentials für einen Anmeldeversuch als gültig betrachtet werden. Die Eigenschaft credentials hat die folgenden Felder:
- AllowCredentials: wenn aktiviert (standardmäßig false) gibt es eine Liste von Credential-IDs an, die zur Authentifizierung des Benutzers zugelassen sind
- ExcludeCredentials: zeigt bei einem gegebenen Benutzernamen alle bereits in der Server-Komponente gespeicherten vorhandenen Credentials an.
- Limit: die maximale Anzahl von Anmeldeinformationen, die gesendet werden, wenn ExcludeCredentials true ist.
WebAuthn Protocol
- WebAuthn Registration: Der Server generiert eine Challenge und sendet sie an den Client, der einen Authenticator (z. B. einen Sicherheitsschlüssel oder ein biometrisches Gerät) verwendet, um ein Schlüsselpaar zu erstellen. Der öffentliche Schlüssel wird zurückgesendet und vom Server für die zukünftige Authentifizierung gespeichert. Weitere Informationen zu den Ereignissen des Registrierungs-Flows finden Sie unten:
- WebAuthn-Authentifizierung: Der Server sendet eine Challenge an den Client, der sie mit dem zuvor registrierten privaten Schlüssel signiert, der im Authenticator gespeichert ist. Die signierte Antwort wird vom Server mit dem gespeicherten Public Key verifiziert, um die Identität des Benutzers zu bestätigen. Nachfolgend finden Sie weitere Informationen über die Ereignisse des Authentifizierungsablaufs:
- MDS: Der Metadata Service (MDS) der FIDO Alliance ist ein zentralisiertes Repository von Metadata Statements, das von Relying Parties verwendet wird, um die Authenticator-Attestierung zu validieren und die Echtheit des Gerätemodells nachzuweisen.

- Authorization: Der Client kann während des Authentifizierungsablaufs ein Bearer-Token vom Server anfordern. Dieses Token kann später verwendet werden, um einen neuen WebSocket oder eine neue HTTP-Verbindung zu öffnen, ohne sich mit Passkeys anmelden zu müssen.