TsgcWSAPIServer_WebAuthn
Only the OpenSSL 3.
Inleiding
Het TsgcWSAPIServer_WebAuthn-component biedt een eenvoudige maar krachtige oplossing voor het implementeren van de WebAuthn Relying Party-server, waardoor wachtwoordloze authenticatie mogelijk is in uw webtoepassing. Een WebAuthn-toepassing bestaat uit een WebAuthn-server die de serverregistratie en -authenticatie afhandelt, en een clientzijdetoepassing die gewoonlijk een JavaScript-toepassing is.
WebAuthn vereist het gebruik van beveiligde verbindingen (SSL/TLS), dus de OpenSSL-bibliotheken moeten worden geïmplementeerd en geconfigureerd met de server.
Alleen de OpenSSL 3.0.0+ API wordt ondersteund, eerdere OpenSSL-versies werken mogelijk niet.
Configuratie
De TsgcWSAPIServer_WebAuthn moet worden gekoppeld aan een HTTP-server, TsgcWebSocketHTTP_Server of TsgcWebSocketServer_HTTPAPI, via de Server-eigenschap. U kunt de servereindpunten configureren die de registratie- en verificatieopties afhandelen, evenals de WebAuthn-opties zoals ondersteunde algoritmen, origins en meer.
Eindpunt-opties
Hier kunt u de server-eindpunten configureren die de HTTP/JavaScript-verzoeken afhandelen voor het gebruik van WebAuthn als authenticator. De component is al geconfigureerd met standaard-eindpunten, maar u kunt ze allemaal aanpassen aan uw behoeften.
- AuthenticationOptions: by default is /sgcWebAuthn/Authentication/Options
- AuthenticationVerify: standaard /sgcWebAuthn/Authentication/Verify
- RegistrationOptions: standaard is /sgcWebAuthn/Registration/Options
- RegistrationVerify: standaard is /sgcWebAuthn/Registration/Verify
- Webauthn: bevat de standaard gebruikte JavaScript-bibliotheek. U kunt deze eigenschap uitschakelen en uw eigen webauthn-bibliotheek gebruiken.
- Test: standaard uitgeschakeld; gebruik alleen om de WebAuthn-functionaliteit te testen.
Voorbeeld: als uw server luistert op domein www.test.com, is het verzoek voor authenticatieopties standaard http://www.test.com/sgcWebAuthn/Authentication/Options
WebAuthn-opties
In deze eigenschap kunt u de hoofdopties van de WebAuthn Server-component configureren.
- RelyingParty: een verplichte eigenschap waarbij de DNS-naam van de server moet worden opgegeven. Voorbeeld: als de server op het domein www.test.com draait, stelt u deze eigenschap in op "www.test.com".
WebAuthn gebruikt origins om same-origin-beleidsbeperkingen af te dwingen, die essentieel zijn voor het voorkomen van phishing en cross-site-aanvallen. Tijdens de WebAuthn-registratie- en verificatieprocessen wordt de origin strikt gevalideerd door de browser en de authenticator.
- Origins: Als de verzoeken van verschillende origins kunnen komen, gebruik dan de eigenschap Origin om de aanvullende origins in te stellen. Voorbeeld: als de verzoeken kunnen komen van login.test.com en www.test.co.uk, configureert u de eigenschap Origins met de waarden: https://login.test.com en https://www.test.co.uk
- TopOrigins: Normaal gesproken vertrouwt WebAuthn op de oorsprong van het aanroepende frame (d.w.z. het frame dat navigator.credentials.create() of navigator.credentials.get() aanroept). Webpagina's kunnen echter worden ingesloten in iframes, die afkomstig kunnen zijn van een andere oorsprong dan de pagina op het hoogste niveau. Dit opent de mogelijkheid voor misbruik of clickjacking-stijlaanvallen. Om dit te beperken, introduceert de WebAuthn Level 2-specificatie TopOrigin waar u de TopOrigins kunt definiëren.
In WebAuthn is crossOrigin een booleaanse parameter die aangeeft of de WebAuthn-bewerking wordt uitgevoerd vanuit een cross-origin-context, zoals een iframe ingesloten vanuit een andere oorsprong dan de top-level browsercontext.
Deze parameter werd geïntroduceerd om browsers en authenticatoren te helpen authenticatieverzoeken veilig af te handelen in ingebedde omgevingen — een veelvoorkomend scenario in moderne webtoepassingen.
- AllowCrossOrigins: indien true, geeft dit aan dat verzoeken van een cross-origin iframe (bijv. een iframe op https://auth.example.com ingebed in een pagina op https://app.example.org) zijn toegestaan. Standaard is dit uitgeschakeld.
WebAuthn ondersteunt een verscheidenheid aan cryptografische algoritmen voor het genereren en verifiëren van publieke sleutelcertificaten. Deze algoritmen worden gebruikt tijdens de registratie van certificaten (met navigator.credentials.create()) en authenticatie (met navigator.credentials.get()), en zorgen voor veilige ondertekening en validatie van uitdagingen met behulp van asymmetrische sleutelparen. De server is standaard geconfigureerd met ES256 en RS256, de meest gebruikte algoritmen. U kunt op elk moment wijzigen welke algoritmen worden ondersteund via de eigenschap Algorithms. De volgende algoritmen worden ondersteund:
- ES256
- ES384
- ES512
- RS256
- RS384
- RS512
- PS256
- PS384
- PS512
- RS1
- EdDSA
In WebAuthn is attestatie een optioneel mechanisme waarmee de authenticator (bijv. apparaat of beveiligingssleutel) informatie kan verstrekken over zijn fabrikant, model en beveiligingskenmerken tijdens het aanmaken van een credential. Deze informatie helpt de Relying Party (RP) te beslissen of zij de authenticator vertrouwt.
Verschillende attestation-formaten definiëren hoe deze gegevens zijn gestructureerd en geverifieerd. Drie veelgebruikte formaten zijn android-key, packed, en andere zoals fido-u2f, apple of none. Standaard zijn alle attestation-formaten ingeschakeld. Hieronder vindt u de lijst met ondersteunde attestation-formaten:
- NoneAttestation: in dit geval worden geen attestatiegegevens geretourneerd. Geeft prioriteit aan gebruikersprivacy door blootstelling van apparaat-ID's te vermijden. Gebruikelijk in toepassingen die zich niet bekommeren om de herkomst van het apparaat.
- PackedAttestation: is een flexibel, compact formaat dat door veel authenticators wordt gebruikt. De authenticator retourneert een attestatiecertificaat en handtekening. Kan zijn: Volledige attestatie: Ondertekend met een door de leverancier verstrekte sleutel en certificaat of Zelfattestatatie: Ondertekend met de privésleutel van de referentie. Het meest gebruikt op verschillende platforms (bijv. YubiKey, Windows Hello).
- TPMAttestation: Gebruikt door apparaten met een Trusted Platform Module (TPM). Attestatie is ondertekend met sleutels van de TPM en bevat een certificaatketen. Gebruikt door zakelijke desktops/laptops met TPM-chips (bijv. Windows-machines).
- AndroidKeyAttestation: Gebruikt door Android-apparaten met de Android Keystore. De sleutel wordt gegenereerd in hardware en de attestatie bevat informatie die is ondertekend door een certificaatketen die is uitgegeven door de apparaatfabrikant. Wordt gebruikt door Android-telefoons met door hardware ondersteunde keystores (TEE of StrongBox).
- AppleAttestation: Gebruikt door Apple-platformauthenticators, zoals Touch ID en Face ID. Attestatie wordt gegenereerd door de interne Apple API's en bevat een speciaal certificaatformaat. Gebruikt op Safari met Apple-biometrie.
- FidoU2FAttestation: Verouderd attestatieformaat gebruikt door FIDO U2F-authenticators. Retourneert een U2F-compatibel certificaat en handtekening. Wordt gebruikt door oudere beveiligingssleutels (bijv. vroege YubiKeys) die FIDO U2F ondersteunen.
In de WebAuthn API is AllowCredentials een optioneel veld dat wordt gebruikt tijdens het authenticatieproces (via navigator.credentials.get()). Het specificeert een lijst van credential-ID's die de gebruiker mogen authenticeren voor een bepaalde Relying Party (RP). Dit mechanisme stelt de RP in staat te bepalen welke credentials geldig zijn voor een inlogpoging. De eigenschap credentials heeft de volgende velden:
- AllowCredentials: indien ingeschakeld (standaard uitgeschakeld) specificeert een lijst met credential-ID's die zijn toegestaan om de gebruiker te authenticeren
- ExcludeCredentials: toont bij een gegeven gebruikersnaam alle bestaande inloggegevens die al zijn opgeslagen in de servercomponent.
- Limit: het maximale aantal inloggegevens dat wordt verzonden wanneer ExcludeCredentials true is.
WebAuthn Protocol
- WebAuthn-registratie: De server genereert een uitdaging en stuurt deze naar de client, die een authenticator (bijv. beveiligingssleutel of biometrisch apparaat) gebruikt om een sleutelpaar te maken. De publieke sleutel wordt teruggestuurd en opgeslagen door de server voor toekomstige authenticatie. Hieronder vindt u meer informatie over de registratiestroom-gebeurtenissen:
- WebAuthn-authenticatie: De server stuurt een uitdaging naar de client, die deze ondertekent met behulp van de eerder geregistreerde privésleutel die is opgeslagen in de authenticator. Het ondertekende antwoord wordt door de server geverifieerd met de opgeslagen publieke sleutel om de identiteit van de gebruiker te bevestigen. Hieronder vindt u meer informatie over de authenticatiestroom-gebeurtenissen:
- MDS: De FIDO Alliance Metadata Service (MDS) is een gecentraliseerde opslagplaats van Metadata Statements die wordt gebruikt door vertrouwende partijen om authenticator-attestatie te valideren en de echtheid van het apparaatmodel te bewijzen.
- Authorization: De client kan tijdens de authenticatieflow een bearertoken bij de server aanvragen. Dit token kan later worden gebruikt om een nieuwe WebSocket- of HTTP-verbinding te openen zonder dat hoeft te worden aangemeld met passkeys.
Referentie
- Eigenschappen — 4 eigenschappen beschikbaar op de component.
- Methoden — 8 publieke methoden.
- Gebeurtenissen — 15 gebeurtenissen die u kunt afhandelen.