Oriëntatie van toegangssleutels

Webfuncties: Webverificatie

Deze handleiding biedt een uitgebreide, actiegerichte oriëntatie voor de implementatie van beveiligde, framework-agnostische verificatie met toegangssleutels en beheer van inloggegevens in moderne web-apps.

1. Kernvereisten voor toegangssleutels

Toegangssleutels zijn afhankelijk van de Web Authentication API (WebAuthn), die strenge, overkoepelende beveiligingsbeperkingen oplegt waaraan moet worden voldaan voordat een implementatiepoging wordt gedaan:

  • Secure Contexts: WebAuthn-methoden (navigator.credentials.create en navigator.credentials.get) zijn strikt afgeschermd achter Secure Contexts. Apps MOETEN worden uitgevoerd op https:// in productie of http://localhost voor lokale ontwikkeling.
  • Relying Party (RP) ID: Elke inloggegeven is gekoppeld aan een RP-ID (in wezen de domeinnaam van de app). De RP-ID die is doorgegeven in de opties aan de serverzijde MOET overeenkomen met of een geldige extensie zijn van de domeinnaam van de huidige oorsprong (bijv. example.com is geldig voor login.example.com). Niet-overeenkomende waarden leiden tot SecurityError-uitzonderingen aan de clientzijde.

2. De UX-waarschuwing voor de AAGUID

De Authenticator Attestation Globally Unique Identifier (AAGUID) is een 128-bits ID die wordt geretourneerd in de registratieattestgegevens en die het model/de provider van de authenticator vertegenwoordigt (bijvoorbeeld Google Wachtwoordmanager, iCloud-sleutelhanger, 1Password).

  • Alleen UX-hints: Afhankelijke partijen MOETEN de AAGUID uitsluitend gebruiken voor UX-hints (zoals de naam en het icoon van de toegangssleutelprovider weergeven in een beheerlijst om de gebruiker te helpen).
  • Geen beveiligingsafhankelijkheden: Apps mogen de AAGUID NIET gebruiken voor cryptografische beveiliging of toegangsbeslissingen. Platformtoegangssleutels bieden op dit moment geen cryptografische attestatie voor hun AAGUID's. Dit betekent dat ze kunnen worden gewijzigd of gesimuleerd door user-agents.

3. Losgekoppelde bibliotheekaanbevelingen

Voor de generatie van backend FIDO2/WebAuthn-opties en handtekeningverificatie MOETEN ontwikkelaars vertrouwen op gecontroleerde open source-bibliotheken per taal in plaats van handmatige cryptografie:

  • JavaScript/TypeScript: SimpleWebAuthn (github.com/MasterKale/SimpleWebAuthn)
  • Python: py_webauthn (github.com/duo-labs/py_webauthn)
  • Java: Java WebAuthn Server (github.com/Yubico/java-webauthn-server), WebAuthn4J (github.com/webauthn4j/webauthn4j)
  • .NET: .NET-bibliotheek voor FIDO2 (github.com/abergs/fido2-net-lib)
  • Go: WebAuthn Go Library (github.com/go-webauthn/webauthn)
  • Ruby: WebAuthn Ruby (github.com/cedarcode/webauthn-ruby)
  • PHP: WebAuthn Framework (github.com/web-auth/webauthn-framework)

4. Referentiematrix voor use cases

Zoek de overeenkomende use case hieronder en haal de volledige implementatiehandleiding op. Elke use case heeft essentiële API's (PublicKeyCredential.parseCreationOptionsFromJSON, parseRequestOptionsFromJSON, signalAllAcceptedCredentials, signalCurrentUserDetails, signalUnknownCredential, voorwaardelijke bemiddeling, AAGUID-verwerking, enzovoort) die alleen worden beschreven in de handleiding per use case. Sla deze ophaalstap NIET over en vervang de wrappers van bibliotheken van derden (zoals startAuthentication/startRegistration van SimpleWebAuthn) NIET op de client. Roep de native WebAuthn-browser-API's rechtstreeks aan. De bibliotheekaanbevelingen in Artikel 3 zijn alleen van toepassing op de serverzijde (FIDO2-verificatie aan de backend).

Specifieke implementatiegegevens voor toegangssleutels en WebAuthn worden toegewezen aan de volgende handleidingen: