Web Authentication API

WebAuthn-Konzepte und Verwendung

WebAuthn verwendet asymmetrische (Public-Key-)Kryptographie anstelle von Passwrtern oder SMS-Textnachrichten zur Registrierung, Authentifizierung und Multi-Faktor-Authentifizierung auf Websites. Dies hat einige Vorteile:

• Schutz vor Phishing: Ein Angreifer, der eine geflschte Anmeldeseite erstellt, kann sich nicht als Benutzer anmelden, da die Signatur mit dem Origin der Website wechselt.
• Geringerer Schaden bei Datenschutzverletzungen: Entwickler bentigen nicht, den ffentlichen Schlssel zu hashen, und wenn ein Angreifer Zugang zum ffentlichen Schlssel erhlt, der zur Authentifizierung verwendet wird, kann er sich nicht authentifizieren, da der private Schlssel erforderlich ist.
• Unverwundbar gegen Passwortangriffe: Einige Benutzer knnen Passwrter wiederverwenden, und ein Angreifer knnte das Passwort des Benutzers fr eine andere Website erlangen (z. B. ber eine Datenverletzung). Auerdem sind Textpasswrter viel leichter durch Brute-Force zu knacken als eine digitale Signatur.

Viele Websites haben bereits Seiten, die es Benutzern ermglichen, neue Konten zu registrieren oder sich in ein bestehendes Konto einzuloggen, und WebAuthn ersetzt oder verbessert den Authentifizierungsteil des Systems. Es erweitert die Credential Management API, abstrahiert die Kommunikation zwischen dem Benutzeragenten und einem Authenticator und bietet die folgende neue Funktionalitt:

• Wenn navigator.credentials.create() mit der Option publicKey verwendet wird, erstellt der Benutzeragent neue Anmeldeinformationen ber einen Authenticator entweder um ein neues Konto zu registrieren oder um ein neues asymmetrisches Schlsselpaar mit einem bestehenden Konto zu verknpfen.
  • Bei der Registrierung eines neuen Kontos werden diese Anmeldeinformationen auf einem Server gespeichert (auch als Dienst oder Vertrauenspartei bezeichnet) und knnen anschlieend verwendet werden, um sich anzumelden.
  • Das asymmetrische Schlsselpaar wird im Authenticator gespeichert, der dann verwendet werden kann, um sich bei einer Vertrauenspartei zu authentifizieren, beispielsweise whrend der MFA. Der Authenticator kann entweder in den Benutzeragenten eingebettet sein, in ein Betriebssystem, wie Windows Hello, oder es kann sich um einen physischen Token handelt, wie z. B. einen USB- oder Bluetooth-Sicherheitsschlssel.
• Wenn navigator.credentials.get() mit der Option publicKey verwendet wird, nutzt der Benutzeragent ein vorhandenes Set von Anmeldeinformationen, um sich bei einer Vertrauenspartei zu authentifizieren (entweder als primre Anmeldung oder um einen zustzlichen Faktor whrend der MFA bereitzustellen, wie oben beschrieben).

In ihren grundlegendsten Formen empfangen sowohl create() als auch get() eine sehr groe Zufallszahl, den sogenannten "Challenge", vom Server und senden den Challenge, der mit dem privaten Schlssel signiert wurde, zurck an den Server. Dadurch wird dem Server bewiesen, dass ein Benutzer den privaten Schlssel besitzt, der fr die Authentifizierung erforderlich ist, ohne Geheimnisse ber das Netzwerk zu offenbaren.

Erstellen eines Schlsselpaares und Registrieren eines Benutzers

Um zu veranschaulichen, wie der Prozess der Erstellung von Anmeldeinformationen funktioniert, beschreiben wir den typischen Ablauf, der auftritt, wenn ein Benutzer ein Anmeldeinformation bei einer Vertrauenspartei registrieren mchte:

1. Der Server der Vertrauenspartei sendet Benutzerinformationen und Informationen zur Vertrauenspartei zusammen mit dem "Challenge" an die Web-App, die den Registrierungsprozess bearbeitet, ber einen geeigneten sicheren Mechanismus (zum Beispiel Fetch oder XMLHttpRequest).

   Hinweis: Das Format zum Teilen von Informationen zwischen dem Server der Vertrauenspartei und der Web-App wird von der Anwendung bestimmt. Ein empfohlener Ansatz besteht darin, JSON-Typreprsentations-Objekte fr Anmeldeinformationen und Anmeldeoptions auszutauschen. Bequemlichkeitsmethoden wurden in PublicKeyCredential erstellt, um von JSON-Darstellungen in die von den Authentifizierungs-APIs bentigte Form konvertieren: parseCreationOptionsFromJSON(), parseRequestOptionsFromJSON() und PublicKeyCredential.toJSON().

2. Die Web-App initiiert die Erstellung eines neuen Anmeldeinformations ber den Authenticator, im Auftrag der Vertrauenspartei, ber einen Aufruf von navigator.credentials.create(). Dieser Aufruf erhlt eine publicKey-Option, die die Gertefhigkeiten angibt, z. B. ob das Gert seine eigene Benutzerautentifikation bereitstellt (zum Beispiel mit biometrischen Daten).

   Ein typischer create()-Aufruf knnte folgendermaen aussehen:

   js

   let credential = await navigator.credentials.create({
     publicKey: {
       challenge: new Uint8Array([117, 61, 252, 231, 191, 241 /*  */]),
       rp: { id: "acme.com", name: "ACME Corporation" },
       user: {
         id: new Uint8Array([79, 252, 83, 72, 214, 7, 89, 26]),
         name: "jamiedoe",
         displayName: "Jamie Doe",
       },
       pubKeyCredParams: [{ type: "public-key", alg: -7 }],
     },
   });
   

   Die Parameter des create()-Aufrufs werden dem Authenticator bergeben, zusammen mit einem SHA-256-Hash, der signiert wird, um sicherzustellen, dass er nicht manipuliert wurde.

3. Nachdem der Authenticator die Zustimmung des Benutzers erhalten hat, generiert er ein Schlsselpaar und gibt den ffentlichen Schlssel und die optional signierte Attestation an die Web-App zurck. Dies wird bereitgestellt, wenn das von create() zurckgegebene Promise erfllt ist, in Form eines PublicKeyCredential-Objekt-Instanz (die PublicKeyCredential.response Eigenschaft enthlt die Attestationsinformationen).

4. Die Web-App leitet das PublicKeyCredential an den Server der Vertrauenspartei weiter, erneut mit einem geeigneten Mechanismus.

5. Der Server der Vertrauenspartei speichert den ffentlichen Schlssel zusammen mit der Benutzeridentitt, um die Anmeldeinformation fr zuknftige Authentifizierungen zu merken. Whrend dieses Prozesses fhrt er eine Reihe von berprfungen durch, um sicherzustellen, dass die Registrierung vollstndig und nicht manipuliert war. Dazu gehren:

   1. berprfung, dass der Challenge derselbe ist wie der, der gesendet wurde.
   2. Sicherstellung, dass der Origin der erwartete war.
   3. Validierung, dass die Signatur und die Attestation die richtige Zertifikatskette fr das spezifische Modell des Authenticator verwenden, der das Schlsselpaar ursprnglich generiert hat.

Authentifizierung eines Benutzers

Nachdem sich ein Benutzer mit WebAuthn registriert hat, kann er sich mit dem Dienst authentifizieren (einloggen). Der Authentifizierungsablauf sieht dem Registrierungsablauf hnlich aus, die wesentlichen Unterschiede bestehen darin, dass die Authentifizierung:

1. Keine Benutzer- oder Vertrauenspartei-Informationen erfordert
2. Ein Assertion mit dem zuvor generierten Schlsselpaar fr den Dienst erstellt, anstatt mit dem Schlsselpaar des Authenticators.

Ein typischer Authentifizierungsablauf sieht wie folgt aus:

1. Die Vertrauenspartei erstellt einen "Challenge" und sendet ihn zusammen mit einer Liste von Vertrauenspartei- und Benutzeranmeldeinformationen an den Benutzeragenten ber einen geeigneten sicheren Mechanismus. Sie kann auch angeben, wo nach der Anmeldeinformation gesucht werden soll, z. B. auf einem lokalen integrierten Authenticator, oder auf einem externen ber USB, BLE usw.

2. Der Browser bittet den Authenticator, den Challenge ber einen Aufruf von navigator.credentials.get() zu signieren, dem die Anmeldeinformationen in einer publicKey-Option bergeben werden.

   Ein typischer get()-Aufruf knnte folgendermaen aussehen:

   js

   let credential = await navigator.credentials.get({
     publicKey: {
       challenge: new Uint8Array([139, 66, 181, 87, 7, 203 /*  */]),
       rpId: "acme.com",
       allowCredentials: [
         {
           type: "public-key",
           id: new Uint8Array([64, 66, 25, 78, 168, 226, 174 /*  */]),
         },
       ],
       userVerification: "required",
     },
   });
   

   Die Parameter des get()-Aufrufs werden dem Authenticator bergeben, um die Authentifizierung zu bearbeiten.

3. Wenn der Authenticator eine der gegebenen Anmeldeinformationen enthlt und den Challenge erfolgreich signieren kann, gibt er eine signierte Assertion an die Web-App zurck, nachdem er die Zustimmung des Benutzers erhalten hat. Dies wird bereitgestellt, wenn das von get() zurckgegebene Promise erfllt ist, in Form eines PublicKeyCredential-Objekt-Instanz (die PublicKeyCredential.response Eigenschaft enthlt die Assertion-Informationen).

4. Die Web-App leitet die signierte Assertion an den Server der Vertrauenspartei zur Validierung weiter. Die Validierungsprfungen umfassen:

   1. Verwendung des ffentlichen Schlssels, der whrend der Registrierungsanforderung gespeichert wurde, um die Signatur durch den Authenticator zu validieren.
   2. Sicherstellung, dass der von dem Authenticator signierte Challenge dem Challenge entspricht, der vom Server generiert wurde.
   3. berprfung, dass die ID der Vertrauenspartei diejenige ist, die fr diesen Dienst erwartet wird.

5. Sobald der Server dies berprft hat, wird der Authentifizierungsfluss als erfolgreich angesehen.

Entdeckbare und nicht-entdeckbare Anmeldeinformationen

Die WebAuthn-API unterscheidet zwischen zwei Arten von Public-Key-Anmeldeinformationen:

• Entdeckbare Anmeldeinformationen, auch bekannt als resident keys

• Nicht-entdeckbare Anmeldeinformationen, auch bekannt als nicht-resident keys

Bei nicht-entdeckbaren Anmeldeinformationen werden das private Schlsselmater ial sowie zustzliche Informationen wie der Benutzername und die ID der RP auerhalb des Authenticators gespeichert, typischerweise auf dem RP-Server (deshalb werden diese Anmeldeinformationen auch manchmal als Server-seitige Anmeldeinformationen bezeichnet). Um den privaten Schlssel sicher auf dem Server zu halten, wird er mit einem im Authenticator gespeicherten Hauptschlssel verschlsselt und der resultierende Chiffretext wird als die ID der Anmeldeinformation verwendet.

Wenn der Authenticator eine nicht-entdeckbare Anmeldeinformation generiert, dann:

1. Generiert er das Schlsselpaar, das zur Authentifizierung des Benutzers verwendet wird.
2. Verschlsselt er den privaten Schlssel und andere Daten mit einem im Authenticator gespeicherten Hauptschlssel.
3. Gibt er den resultierenden Chiffretext als neue Anmeldeinformationen-ID an die RP zurck, zusammen mit dem Rest der Anmeldeinformationen, wie dem ffentlichen Schlssel.

Wenn die RP sich mit einer nicht-entdeckbaren Anmeldeinformation anmelden muss:

1. Gibt die RP die Anmeldeinformationen-ID in den Aufruf CredentialsContainer.get() ein.
2. Entschlsselt der Authenticator den Wert der Anmeldeinformationen-ID in den privaten Schlssel und andere Daten, unter Verwendung des im Authenticator gespeicherten Hauptschlssels.
3. Verwendet der Authenticator den privaten Schlssel, um eine Assertion zu signieren.

Bei entdeckbaren Anmeldeinformationen speichert der Authenticator selbst:

• Das private Schlsselmater ial, das zur Erstellung von Assertions verwendet wird.
• Den mit der Anmeldeinformation verknpften Benutzernamen.
• Die ID der mit der Anmeldeinformation verknpften RP.

Der Vorteil einer nicht-entdeckbaren Anmeldeinformation besteht darin, dass der Authenticator keine spezifischen Anmeldedaten speichern muss, was bedeutet, dass er theoretisch eine unbegrenzte Anzahl an Anmeldedaten untersttzen knnte.

Der Nachteil besteht darin, dass der Benutzer, um eine nicht-entdeckbare Anmeldeinformation verwenden zu knnen, zuerst den Benutzernamen angeben muss, mit dem er sich anmelden mchte, was die RP dann verwenden kann, um ein entsprechendes Set von Anmeldeinformations-IDs zu finden, die dem Browser dem Authenticator zur Verfgung stellen kann.

Im Gegensatz dazu kann der Browser mit entdeckbaren Anmeldeinformationen:

• Informationen ber alle entdeckbaren Anmeldeinformationen, die mit der RP verknpft sind, vom Authenticator abrufen.
• Deren zugehrige Benutzernamen dem Benutzer anzeigen.
• Den Benutzer einladen, denjenigen auszuwhlen, mit dem er sich anmelden mchte.

Dies ist die Grundlage der Autofill-UI-Funktion.

Verwenden Sie die Option residentKey in PublicKeyCredentialCreationOptions, um zu steuern, ob eine neue Public-Key-Anmeldeinformation entdeckbar oder nicht-entdeckbar ist.

Autofill-UI

Autofill-UI, auch als bedingte Vermittlung bezeichnet, ist eine Funktion, die es Benutzern erleichtert, mit ffentlichen Schlsselanmeldeinformationen zu arbeiten, insbesondere wenn sie auch Passwrter fr die Website haben.

Es wird erwartet, dass Websites, die Passkeys einfhren, diese typischerweise zustzlich zum bestehenden Support fr passwortbasierte Authentifizierung hinzufgen, sodass ein Benutzer fr eine gegebene Website ein Passwort, einen oder mehrere Passkeys oder beides haben kann. In dieser Situation kann eine Benutzeroberflche, die sie fragt, mit welcher Methode sie sich anmelden mchten, verwirrend sein: Sie erinnern sich mglicherweise dann nicht mehr daran, welche Methode sie fr welches Konto haben. Die Autofill-UI hilft bei diesem Problem, indem sie Benutzer einldt, sich mit einem Passkey anzumelden, nur wenn ein geeigneter Passkey derzeit verfgbar ist.

Um die Autofill-UI zu aktivieren, enthlt die Anmeldeseite der Website ein Formular, das sie zur Anmeldung einldt. In dem Feld fr den Benutzernamen enthlt die Website einen autocomplete-Wert von "webauthn":

<input type="text" name="username" autocomplete="username webauthn" />

Wenn die Seite geladen wird, prft die Website zunchst, ob bedingte Vermittlung untersttzt wird, und ruft, falls dies der Fall ist, CredentialsContainer.get() auf. Der Aufruf:

• bermittelt "conditional" als Wert der mediation-Option.
• Lsst die allowCredentials-Option weg, um anzugeben, dass alle anwendbaren Anmeldeinformationen akzeptabel sind.

const supported = await PublicKeyCredential.isConditionalMediationAvailable();
if (supported) {
  const options = {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
    // allowCredentials is omitted here
  };

  const assertion = await navigator.credentials.get({
    publicKey: options,
    mediation: "conditional",
  });
}

Dies wird warten, bis der Benutzer mit dem Benutzernamen-Feld interagiert.

Wenn und falls der Benutzer mit dem Feld interagiert, wird der Browser alle verfgbaren Authenticators nach ffentlichen Schlsselanmeldeinformationen fragen, die verwendet werden knnen, um sich auf dieser Website anzumelden, und die zugehrigen Benutzernamen als Autofill-Optionen fr den Benutzer anzeigen, neben allen gespeicherten Passwrtern fr das Konto. Wenn der Benutzer eine dieser Optionen auswhlt, wird der Browser diese Anmeldeinformation verwenden, um den Benutzer anzumelden.

Dies ermglicht es einer Website im Wesentlichen, ein einheitliches Autofill anzubieten, das sowohl Passwrter als auch ffentliche Schlsselanmeldeinformationen fr ein einzelnes Konto umfasst.

Methoden zur Synchronisierung von entdeckbaren Anmeldeinformationen

Es ist mglich, dass die im Authenticator eines Benutzers gespeicherten Informationen ber eine entdeckbare Anmeldeinformation nicht mehr mit dem Server der Vertrauenspartei synchron sind. Dies knnte auftreten, wenn der Benutzer eine Anmeldeinformation lscht oder seinen Benutzer-/Anzeigenamen in der RP-Web-App ndert, ohne den Authenticator zu aktualisieren.

Die API bietet Methoden, mit denen der Server der Vertrauenspartei nderungen an den Authenticator signalisieren kann, damit er seine gespeicherten Anmeldeinformationen aktualisieren kann:

• PublicKeyCredential.signalAllAcceptedCredentials(): Signalisiert dem Authenticator alle gltigen Anmeldeinformationen-IDs, die der RP-Server noch fr einen bestimmten Benutzer hlt.
• PublicKeyCredential.signalCurrentUserDetails(): Signalisiert dem Authenticator, dass ein bestimmter Benutzer seinen Benutzer- und/oder Anzeigenamen auf dem RP-Server aktualisiert hat.
• PublicKeyCredential.signalUnknownCredential(): Signalisiert dem Authenticator, dass eine Anmeldeinformationen-ID nicht vom RP-Server erkannt wurde.

Es mag so aussehen, als htten signalUnknownCredential() und signalAllAcceptedCredentials() hnliche Zwecke, also in welcher Situation sollte jeder verwendet werden?

• signalAllAcceptedCredentials() sollte nach jedem erfolgreichen Login und wenn der Benutzer eingeloggt ist, aufgerufen werden, um den Status ihrer Anmeldedaten zu aktualisieren. Es darf nur aufgerufen werden, wenn ein Benutzer authentifiziert ist, da es die gesamte Liste der credentialIds fr einen bestimmten Benutzer teilt. Dies wrde ein Datenschutzleck verursachen, wenn der Benutzer nicht authentifiziert ist.
• signalUnknownCredential() sollte nach einem erfolglosen Login aufgerufen werden, um dem Authenticator zu signalisieren, dass die credentialId der ausgewhlten Anmeldeinformation nicht validiert werden kann und entfernt werden sollte. Die Methode kann sicher aufgerufen werden, wenn der Benutzer nicht authentifiziert ist, da sie eine einzelne credentialId an den Authenticator bergibt diejenige, mit der der Client gerade versucht hat, sich zu authentifizieren und keine Benutzerinformationen.

Arbeitsablufe nach Client-Fhigkeiten anpassen

Die Anmelde- und Login-Arbeitsablufe knnen auf Basis der Fhigkeiten des WebAuthn-Clients (Browser) angepasst werden. Die statische Methode PublicKeyCredential.getClientCapabilities() kann verwendet werden, um diese Fhigkeiten abzufragen; sie gibt ein Objekt zurck, bei dem jeder Schlssel sich auf eine WebAuthn-Fhigkeit oder -Erweiterung bezieht, und jeder Wert ist ein Boolean, der die Untersttzung fr diese Funktion anzeigt.

Dies kann verwendet werden, um beispielsweise zu berprfen:

• Client-Untersttzung fr verschiedene Authenticators wie Passkeys oder biometrische Benutzerverifizierung.
• Ob der Client Methoden zur Synchronisierung von Vertrauenspartei- und Authenticator-Anmeldeinformationen untersttzt.
• Ob der Client zulsst, dass ein einzelner Passkey auf verschiedenen Websites mit demselben Ursprung verwendet wird.

Der folgende Code zeigt, wie Sie getClientCapabilities() verwenden knnten, um zu berprfen, ob der Client Authenticators untersttzt, die biometrische Benutzerverifizierung bieten. Beachten Sie, dass die tatschlich durchgefhrten Aktionen von Ihrer Seite abhngen. Fr Websites, die biometrische Authentifizierung erfordern, knnten Sie die Login-Benutzeroberflche durch eine Nachricht ersetzen, die anzeigt, dass biometrische Authentifizierung bentigt wird, und der Benutzer sollte versuchen, einen anderen Browser oder Gert zu verwenden.

async function checkIsUserVerifyingPlatformAuthenticatorAvailable() {
  const capabilities = await PublicKeyCredential.getClientCapabilities();
  // Check the capability: userVerifyingPlatformAuthenticator
  if (capabilities.userVerifyingPlatformAuthenticator) {
    // Perform actions if biometric support is available
  } else {
    // Perform actions if biometric support is not available.
  }
}

Zugriffskontrolle auf die API

Die Verfgbarkeit von WebAuthn kann mittels einer Permissions Policy gesteuert werden, wobei zwei Direktiven besonders spezifiziert werden:

• publickey-credentials-create: Steuert die Verfgbarkeit von navigator.credentials.create() mit der Option publicKey.
• publickey-credentials-get: Steuert die Verfgbarkeit von navigator.credentials.get() mit der Option publicKey.

Beide Direktiven haben einen Standard-Wert fr die Allowlist von "self", was bedeutet, dass diese Methoden standardmig in den Kontexten von Top-Level-Dokumenten verwendet werden knnen. Zudem kann get() in geschachtelten Browsing-Kontexten verwendet werden, die vom selben Origin wie das oberste Dokument geladen werden. get() und create() knnen in geschachtelten Browsing-Kontexten verwendet werden, die von anderen Origins als das oberste Dokument geladen werden (d.h. in bergreifenden <iframes>), wenn dies von den jeweiligen publickey-credentials-get und publickey-credentials-create Permissions-Policy-Direktiven erlaubt wird. Fr bergreifende create()-Aufrufe, wo die Erlaubnis durch allow= in einem iframe erteilt wurde, muss der Frame auch flchtige Aktivierung haben.

Grundlegende Zugriffskontrolle

Wenn Sie den Zugriff nur auf eine bestimmte Subdomain erlauben mchten, knnten Sie dies so angeben:

Permissions-Policy: publickey-credentials-get=("https://subdomain.example.com")
Permissions-Policy: publickey-credentials-create=("https://subdomain.example.com")

Zulassen eingebetteter Aufrufe von create und get() in einem <iframe>

Wenn Sie mit get() oder create() in einem <iframe> authentifizieren mchten, mssen Sie ein paar Schritte befolgen:

1. Die Website, die die Seite der Vertrauenspartei einbettet, muss die Erlaubnis ber ein allow-Attribut geben:

   • Wenn Sie get() verwenden:

     html

     <iframe
       src="https://auth.provider.com"
       allow="publickey-credentials-get *">
     </iframe>
     

   • Wenn Sie create() verwenden:

     html

     <iframe
       src="https://auth.provider.com"
       allow="publickey-credentials-create 'self' https://a.auth.provider.com https://b.auth.provider.com">
     </iframe>
     

     Das <iframe> muss auch eine flchtige Aktivierung haben, wenn create() bergreifend aufgerufen wird.

2. Die Website der Vertrauenspartei muss die oben genannten Zugriffe ber einen Permissions-Policy-Header erlauben:

   http

   Permissions-Policy: publickey-credentials-get=*
   Permissions-Policy: publickey-credentials-create=*
   

   Oder um nur eine bestimmte URL zu erlauben, die Website der Vertrauenspartei in einem <iframe> einzubetten:

   http

   Permissions-Policy: publickey-credentials-get=("https://subdomain.example.com")
   Permissions-Policy: publickey-credentials-create=("https://*.auth.provider.com")
   

Schnittstellen

AuthenticatorAssertionResponse

Bietet einem Dienst einen Nachweis, dass ein Authenticator das ntige Schlsselpaar hat, um eine Authentifizierungsanfrage erfolgreich zu bearbeiten, die durch einen Aufruf von CredentialsContainer.get() initiiert wurde. Verfgbar in der response-Eigenschaft der PublicKeyCredential-Instanz, die erhalten wird, wenn das get() Promise erfllt wird.

AuthenticatorAttestationResponse

Das Ergebnis einer WebAuthn-Anmeldeinformationsregistrierung (d.h. eines Aufrufs von CredentialsContainer.create()). Es enthlt Informationen ber die Anmeldeinformation, die der Server bentigt, um WebAuthn-Assertions durchzufhren, wie z. B. deren Anmeldeinformations-ID und ffentlicher Schlssel. Verfgbar in der response-Eigenschaft der PublicKeyCredential-Instanz, die erhalten wird, wenn das create() Promise erfllt wird.

AuthenticatorResponse

Die Basisschnittstelle fr AuthenticatorAttestationResponse und AuthenticatorAssertionResponse.

PublicKeyCredential

Bietet Informationen zu einem ffentlichen/privaten Schlsselpaar, das eine Anmeldeinformation fr die Anmeldung bei einem Dienst mithilfe eines Asymmetrischen Schlsselpaares darstellt, das nicht phishable ist und gegen Datenverletzungen resistent ist, anstelle eines Passworts. Erhalten, wenn das Promise, das durch einen Aufruf von create() oder get() zurckgegeben wird, erfllt wird.

Erweiterungen zu anderen Schnittstellen

CredentialsContainer.create(), die publicKey-Option

Ein Aufruf von create() mit einer publicKey-Option initiiert die Erstellung neuer asymmetrischer Schlssel-Anmeldeinformationen ber einen Authenticator, wie oben erklrt.

CredentialsContainer.get(), die publicKey-Option

Ein Aufruf von get() mit einer publicKey-Option instruiert den Benutzeragenten, ein bestehendes Set von Anmeldeinformationen zu verwenden, um sich bei einer Vertrauenspartei zu authentifizieren.

Beispiele

Demo-Websites

• Mozilla Demo Website und deren Quellcode.
• Google Demo Website und deren Quellcode.
• WebAuthn.io Demo Website und deren Quellcode.
• github.com/webauthn-open-source und deren Client-Quellcode und Server-Quellcode

Verwendungsbeispiel

// sample arguments for registration
const createCredentialDefaultArgs = {
  publicKey: {
    // Relying Party (a.k.a. - Service):
    rp: {
      name: "Acme",
    },
    // User:
    user: {
      id: new Uint8Array(16),
      name: "carina.p.anand@example.com",
      displayName: "Carina P. Anand",
    },
    pubKeyCredParams: [
      {
        type: "public-key",
        alg: -7,
      },
    ],
    attestation: "direct",
    timeout: 60000,
    challenge: new Uint8Array([
      // must be a cryptographically random number sent from a server
      0x8c, 0x0a, 0x26, 0xff, 0x22, 0x91, 0xc1, 0xe9, 0xb9, 0x4e, 0x2e, 0x17,
      0x1a, 0x98, 0x6a, 0x73, 0x71, 0x9d, 0x43, 0x48, 0xd5, 0xa7, 0x6a, 0x15,
      0x7e, 0x38, 0x94, 0x52, 0x77, 0x97, 0x0f, 0xef,
    ]).buffer,
  },
};

// sample arguments for login
const getCredentialDefaultArgs = {
  publicKey: {
    timeout: 60000,
    // allowCredentials: [newCredential] // see below
    challenge: new Uint8Array([
      // must be a cryptographically random number sent from a server
      0x79, 0x50, 0x68, 0x71, 0xda, 0xee, 0xee, 0xb9, 0x94, 0xc3, 0xc2, 0x15,
      0x67, 0x65, 0x26, 0x22, 0xe3, 0xf3, 0xab, 0x3b, 0x78, 0x2e, 0xd5, 0x6f,
      0x81, 0x26, 0xe2, 0xa6, 0x01, 0x7d, 0x74, 0x50,
    ]).buffer,
  },
};

// register / create a new credential
navigator.credentials
  .create(createCredentialDefaultArgs)
  .then((cred) => {
    console.log("NEW CREDENTIAL", cred);
    // normally the credential IDs available for an account would come from a server
    // but we can just copy them from above
    const idList = [
      {
        id: cred.rawId,
        transports: ["usb", "nfc", "ble"],
        type: "public-key",
      },
    ];
    getCredentialDefaultArgs.publicKey.allowCredentials = idList;
    return navigator.credentials.get(getCredentialDefaultArgs);
  })
  .then((assertion) => {
    console.log("ASSERTION", assertion);
  })
  .catch((err) => {
    console.log("ERROR", err);
  });

Spezifikationen

Browser-Kompatibilitt