Web-Authentifizierungs-Erweiterungen
Die Web Authentication API verfügt über ein System von Erweiterungen – zusätzliche Funktionalitäten, die während der Erstellung von Anmeldedaten (navigator.credentials.create()
) oder Authentifizierung (navigator.credentials.get()
) angefordert werden können. Dieser Artikel erklärt, wie Sie WebAuthn-Erweiterungen anfordern, Informationen über die Antworten auf diese Anfragen abrufen und welche Erweiterungen verfügbar sind – einschließlich Browser-Unterstützung und erwarteter Eingaben und Ausgaben.
Anleitung zur Verwendung von WebAuthn-Erweiterungen
Beim Aufrufen von navigator.credentials.create()
oder navigator.credentials.get()
kann das erforderliche publicKey
-Objektparameter zum Initiieren eines WebAuthn-Flows eine extensions
-Property enthalten. Der Wert von extensions
ist selbst ein Objekt, dessen Eigenschaften die Eingabewerte für alle Erweiterungen sind, deren Verwendung die relying party in der von Ihnen aufgerufenen Methode anfordern möchte.
Im Hintergrund werden die Eingaben vom Benutzeragenten und/oder dem Authentifizierungsgerät verarbeitet.
Zum Beispiel möchten wir in einem publicKey
-Objekt für einen create()
-Aufruf die Verwendung von zwei Erweiterungen anfordern:
- Die
credProps
-Erweiterung. Relying Parties setzencredProps
, um zu verlangen, dass der Browser der Relying Party mitteilt, ob die Anmeldedaten nach der Registrierung resident/auffindbar sind. Dies ist nützlich, wenncreate()
mitpublicKey.authenticatorSelection.residentKey = "preferred"
aufgerufen wird. Um dies anzufordern, müssen Sie außerdempublicKey.extensions.credProps = true
setzen, wenn der Browser Anmeldedaten erstellt, und je nach Art des verwendeten Authentifizierungsgeräts werden diese auffindbar sein (zum Beispiel würde ein FIDO2-Authenticator sie typischerweise auffindbar machen; ein FIDO1/U2F-Sicherheitsschlüssel wäre nicht auffindbar).credProps
wird nur vom Benutzeragenten verarbeitet. - Die
minPinLength
-Erweiterung ermöglicht es Relying Parties, die Mindest-PIN-Länge des Authentifizierungsgeräts anzufordern. Dazu mussextensions.minPinLength
auftrue
gesetzt werden.minPinLength
wird vom Authentifizierungsgerät verarbeitet, wobei der Benutzeragent nur dazu dient, die Eingabedaten weiterzuleiten.
const 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 }],
authenticatorSelection: {
residentKey: "preferred",
},
extensions: {
credProps: true,
minPinLength: true,
},
};
Wir können dann das publicKey
-Objekt in einen create()
-Aufruf übergeben, um den Anmeldeerstellungsprozess zu starten:
navigator.credentials.create({ publicKey });
Abrufen von Ergebnissen der Erweiterungsanfrage
Wenn erfolgreich, gibt der create()
-Aufruf ein Promise
zurück, das ein PublicKeyCredential
-Objekt auflöst. Sobald die Verarbeitung der Erweiterung abgeschlossen ist, werden die Ergebnisse der Verarbeitung in der Antwort mitgeteilt (obwohl nicht in allen Fällen – es ist möglich, dass Erweiterungen keine Ausgabe haben).
navigator.credentials
.create({ publicKey })
.then((publicKeyCred) => {
const myClientExtResults = publicKeyCred.getClientExtensionResults();
// myClientExtResults will contain the output of processing
// the "credProps" extension
const authData = publicKeyCred.response.getAuthenticatorData();
// authData will contain authenticator data, which will include
// authenticator extension processing results, i.e., minPinLength
})
.catch((err) => {
console.error(err);
});
Wie das obige Codebeispiel zeigt, gibt es zwei verschiedene Orte, um die Ergebnisse Ihrer Ausgabeerweiterungen zu finden:
-
Sie können die Ergebnisse der Erweiterungsverarbeitung des Clients (Benutzeragenten) finden, indem Sie die Methode
PublicKeyCredential.getClientExtensionResults()
aufrufen. Dies gibt eineMap
zurück, wobei jeder Eintrag eine Zeichenfolge zur Identifizierung der Erweiterung als Schlüssel und die Ausgabe der Verarbeitung der Erweiterung durch den Client als Wert enthält. In dem oben genannten Beispiel würde, wenn der Browser diecredProps
-Erweiterung unterstützt und sie korrekt verarbeitet wurde, dasmyClientExtResults
-Map-Objekt einen Eintrag enthalten,"credProps"
, mit einem Wert von{ rk: true }
. Dies würde bestätigen, dass die erstellte Anmeldeinformation tatsächlich auffindbar ist. -
Die Ergebnisse der Erweiterungsverarbeitung durch das Authentifizierungsgerät finden Sie in den Authentifizierungsdaten für den Vorgang:
- Im Fall von
PublicKeyCredential
s, die aus erfolgreichencreate()
-Aufrufen zurückgegeben werden, kann dies über einen Aufruf vonpublicKeyCredential.response.getAuthenticatorData()
zurückgegeben werden. - Im Fall von
PublicKeyCredential
s, die aus erfolgreichenget()
-Aufrufen zurückgegeben werden, finden Sie dies in derpublicKeyCredential.response.authenticatorData
-Eigenschaft.
Authentifizierungsdaten haben die Form eines
ArrayBuffer
mit einer konsistenten Struktur – siehe authenticator data. Die Daten der Erweiterungsergebnisse des Authentifizierungsgeräts befinden sich immer in einem Abschnitt am Ende, als CBOR-Karte, die die Ergebnisse darstellt. SieheAuthenticatorAssertionResponse.authenticatorData
für eine detaillierte Beschreibung der vollständigen Authentifizierungsdatenstruktur.Zurück zu unserem Beispiel: Wenn die relying party autorisiert ist, den
minPinLength
-Wert zu erhalten, würden die Authentifizierungsdaten eine Darstellung davon enthalten:"minPinLength": uint
. - Im Fall von
Verfügbare Erweiterungen
Die folgenden Erweiterungen stellen keine vollständige Liste aller verfügbaren Erweiterungen dar. Wir haben uns entschieden, Erweiterungen zu dokumentieren, von denen wir wissen, dass sie standardisiert und von mindestens einer Rendering-Engine unterstützt werden.
appid
- Nutzbar in: Authentifizierung (
get()
) - Verarbeitet von: Benutzeragent
- Spezifikation: FIDO AppID Erweiterung (appid)
Ermöglicht es einer relying party, eine Behauptung für eine zuvor mit der alten FIDO U2F JavaScript API registrierte Anmeldeinformation anzufordern, um den Aufwand einer erneuten Registrierung der Anmeldeinformation zu vermeiden. Die appid
ist das Äquivalent zu der rpId
in WebAuthn (obwohl zu beachten ist, dass appid
s in Form von URLs vorliegen, während rpId
s in Form von Domains vorliegen).
Eingabe
Die extensions
-Property der publicKey
muss eine appid
-Property enthalten, deren Wert die Anwendungskennzeichnung ist, die in der alten API verwendet wurde. Zum Beispiel:
({
extensions: {
appid: "https://accounts.example.com",
},
});
Sie müssen auch die FIDO U2F-Credential-IDs in der allowCredentials
Property der publicKey
auflisten, zum Beispiel:
({
allowCredentials: [
{
id: arrayBuffer, // needs to contain decoded binary form of id
transports: ["nfc", "usb"],
type: "public-key",
},
],
});
Ausgabe
Gibt appid: true
aus, wenn die appid
erfolgreich für die Behauptung verwendet wurde, oder appid: false
anderenfalls.
appidExclude
- Nutzbar in: Registrierung (
create()
) - Verarbeitet von: Benutzeragent
- Spezifikation: FIDO AppID Ausschluss-Erweiterung (appidExclude)
Ermöglicht es einer relying party, Authentifizierungsgeräte mit bestimmten zuvor registrierten Anmeldeinformationen unter Verwendung der alten FIDO U2F JavaScript API während der Registrierung auszuschließen. Dies ist erforderlich, weil standardmäßig die Inhalte des excludeCredentials
-Felds als WebAuthn-Anmeldeinformationen angesehen werden. Wenn Sie diese Erweiterung verwenden, können Sie alte FIDO U2F-Anmeldeinformationen im excludeCredentials
-Feld einfügen, und sie werden als solche erkannt.
Eingabe
Die extensions
-Property der publicKey
muss eine appidExclude
-Property enthalten, deren Wert der Bezeichner des relying party ist, der anfordert, Authentifizierungsgeräte durch alte FIDO U2F-Anmeldeinformationen auszuschließen. Zum Beispiel:
({
extensions: {
appidExclude: "https://accounts.example.com",
},
});
Sie können dann FIDO U2F-Anmeldeinformationen in der excludeCredentials
Property der publicKey
auflisten, zum Beispiel:
({
excludeCredentials: [
{
id: arrayBuffer, // needs to contain decoded binary form of id
transports: ["nfc", "usb"],
type: "public-key",
},
],
});
Ausgabe
Gibt appidExclude: true
aus, wenn die Erweiterung angewendet wurde, oder appidExclude: false
anderenfalls.
credProps
- Nutzbar in: Registrierung (
create()
) - Verarbeitet von: Benutzeragent
- Spezifikation: Credential Properties Erweiterung (credProps)
Ermöglicht es einer relying party, zusätzliche Informationen/Eigenschaften über die erstellten Anmeldeinformationen anzufordern. Dies ist derzeit nur nützlich, wenn create()
mit publicKey.authenticatorSelection.residentKey = "preferred"
aufgerufen wird; es fordert Informationen darüber an, ob die erstellte Anmeldeinformation auffindbar ist.
Eingabe
Die extensions
-Property der publicKey
muss eine credProps
-Property mit einem Wert von true
enthalten:
({
extensions: {
credProps: true,
},
});
Sie müssen auch authenticatorSelection.requireResidentKey
auf true
setzen, was darauf hinweist, dass ein residenter Schlüssel erforderlich ist.
({
authenticatorSelection: {
requireResidentKey: true,
},
});
Ausgabe
Gibt folgendes aus, wenn das registrierte PublicKeyCredential
eine clientseitig auffindbare Anmeldeinformation ist:
({
credProps: {
rk: true,
},
});
Wenn rk
im Ausgabeergebnis auf false
gesetzt ist, handelt es sich bei der Anmeldeinformation um eine serverseitige Anmeldeinformation. Wenn rk
im Ausgabeergebnis nicht vorhanden ist, ist nicht bekannt, ob die Anmeldeinformation clientseitig auffindbar oder serverseitig ist.
credProtect
- Nutzbar in: Registrierung (
create()
) - Verarbeitet von: Authentifizierungsgerät
- Spezifikation: Credential Protection (credProtect)
Ermöglicht es einer relying party, eine Mindestkreditialschutzrichtlinie anzugeben, wenn eine Anmeldeinformation erstellt wird.
Eingabe
Die extensions
-Property der publicKey
muss eine credentialProtectionPolicy
-Property enthalten, die das Schutzniveau der zu erstellenden Anmeldeinformation angibt, und eine boolesche enforceCredentialProtectionPolicy
-Property, die angibt, ob der create()
-Aufruf scheitern soll, anstatt eine Anmeldeinformation zu erstellen, die nicht der festgelegten Richtlinie entspricht:
({
extensions: {
credentialProtectionPolicy: "userVerificationOptional",
enforceCredentialProtectionPolicy: true,
},
});
Die verfügbaren credentialProtectionPolicy
-Werte sind wie folgt:
"userVerificationOptional"
Experimentell-
Benutzerüberprüfung ist optional. Der entsprechende
credProtect
-Wert, der an den Authentifizierer zur Verarbeitung gesendet wird, ist0x01
. "userVerificationOptionalWithCredentialIDList"
-
Benutzerüberprüfung ist nur optional, wenn die Anmeldeinformation auffindbar ist (d.h. sie ist clientseitig auffindbar). Der entsprechende
credProtect
-Wert, der an den Authentifizierer zur Verarbeitung gesendet wird, ist0x02
. "userVerificationRequired"
-
Benutzerüberprüfung wird immer benötigt. Der entsprechende
credProtect
-Wert, der an den Authentifizierer zur Verarbeitung gesendet wird, ist0x03
.
Hinweis:
Chromium setzt standardmäßig userVerificationOptionalWithCredentialIDList
oder userVerificationRequired
, abhängig von der Anfrageart:
- Chromium fordert ein Schutzniveau von
userVerificationOptionalWithCredentialIDList
an, wenn eine Anmeldeinformation erstellt wird, wennresidentKey
aufpreferred
oderrequired
gesetzt ist. (Das Setzen vonrequireResidentKey
wird genauso behandelt wie required.) Dies stellt sicher, dass der bloße physische Besitz eines Sicherheitsschlüssels nicht ausreicht, um die Abfrage einer auffindbaren Anmeldeinformation für eine bestimmterpId
zu ermöglichen. - Wenn
residentKey
erforderlich ist unduserVerification
bevorzugt ist, wird das Schutzniveau aufuserVerificationRequired
erhöht. Dies stellt sicher, dass der physische Besitz eines Sicherheitsschlüssels die Anmeldung bei einer Website, die keine Benutzerüberprüfung erfordert, nicht ermöglicht. (Dies ist jedoch kein vollständiger Schutz; Websites sollten dennoch sorgfältig die Sicherheit ihrer Benutzer berücksichtigen.) - Wenn die Website ein explizites
credProtect
-Niveau anfordert, wird dies die Standardeinstellungen überschreiben. Diese Standardeinstellungen führen niemals dazu, dass das Schutzniveau niedriger ist als der Standard des Sicherheitsschlüssels, wenn dieser höher ist.
Wenn der Wert von enforceCredentialProtectionPolicy
true
ist, scheitert der create()
-Aufruf, wenn die Richtlinie nicht eingehalten werden kann (z. B. erfordert sie eine Benutzerüberprüfung, aber der Authentifizierer unterstützt keine Benutzerüberprüfung). Wenn er false
ist, wird das System sein Bestes tun, eine Anmeldeinformation zu erstellen, die der Richtlinie entspricht, aber sie wird dennoch eine erstellen, die so nah wie möglich an die Richtlinie heranreicht, wenn dies nicht möglich ist.
Ausgabe
Wenn der create()
-Aufruf erfolgreich ist, werden die Authentifizierungsdaten eine Darstellung des credProtect
-Wertes enthalten, der die festgelegte Richtlinie in folgender Form darstellt:
({ credProtect: 0x01 });
largeBlob
- Nutzbar in: Registrierung (
create()
) und Authentifizierung (get()
) - Verarbeitet von: Benutzeragent
- Spezifikation: Large blob storage extension (largeBlob)
Ermöglicht es einer relying party, Blobs zu speichern, die mit einer Anmeldeinformation auf dem Authentifizierer verknüpft sind – zum Beispiel kann sie direkt Zertifikate speichern, anstatt einen zentralisierten Authentifizierungsdienst zu betreiben.
Eingabe
Während eines create()
-Aufrufs muss die extensions
-Property der publicKey
eine largeBlob
-Property mit folgender Objektstruktur enthalten:
({
extensions: {
largeBlob: {
support: "required",
},
},
});
Der Wert der support
-Property ist eine Zeichenfolge, die folgende sein kann:
"preferred"
: Die Anmeldeinformation wird nach Möglichkeit mit einem Authentifizierer erstellt, der Blobs speichern kann, wird aber dennoch erstellt, wenn nicht. Die Ausgabesupported
Property berichtet über die Fähigkeit des Authentifizierers, Blobs zu speichern."required"
: Die Anmeldeinformation wird mit einem Authentifizierer erstellt, der Blobs speichern kann. Dercreate()
-Aufruf scheitert, wenn dies unmöglich ist.
Während eines get()
-Aufrufs muss die extensions
-Property der publicKey
eine largeBlob
-Property mit einer von zwei Untereigenschaften enthalten – read
oder write
(get()
scheitert, wenn beide vorhanden sind):
Die read
-Property ist ein boolescher Wert. Ein Wert von true
zeigt an, dass die relying party ein zuvor geschriebenes Blob, das mit der behaupteten Anmeldeinformation verknüpft ist, abrufen möchte:
({
extensions: {
largeBlob: {
read: true,
},
},
});
Die write
-Property nimmt als Wert ein ArrayBuffer
, TypedArray
oder DataView
, das ein Blob darstellt, das die relying party neben einer vorhandenen Anmeldeinformation speichern möchte:
({
extensions: {
largeBlob: {
write: arrayBuffer,
},
},
});
Hinweis:
Damit ein Schreibauthentifizierungsvorgang erfolgreich ist, muss publicKey.allowCredentials
nur ein einzelnes Element enthalten, das die Anmeldeinformation darstellt, neben der das Blob gespeichert werden soll.
Ausgabe
Ein erfolgreicher create()
-Aufruf liefert die folgende Erweiterungsausgabe, wenn die registrierte Anmeldeinformation in der Lage ist, Blobs zu speichern:
({
largeBlob: {
supported: true, // false if it cannot store blobs
},
});
Ein get()
-Lesen macht das Blob als ArrayBuffer
in der Erweiterungsausgabe verfügbar, wenn es erfolgreich ist:
({
largeBlob: {
blob: arrayBuffer,
},
});
Hinweis:
Wenn nicht erfolgreich, wird das largeBlob
-Objekt zurückgegeben, aber blob
wird nicht vorhanden sein.
Ein get()
-Schreiben gibt an, ob der Schreibvorgang mit einem written
booleschen Wert in der Erweiterungsausgabe erfolgreich war. Ein Wert von true
bedeutet, dass es erfolgreich auf dem zugehörigen Authentifizierer geschrieben wurde, und false
bedeutet, dass es erfolglos war.
({
largeBlob: {
written: true,
},
});
minPinLength
- Nutzbar in: Registrierung (
create()
) - Verarbeitet von: Authentifizierungsgerät
- Spezifikation: Minimum PIN Length Extension (minPinLength)
Ermöglicht es relying parties, die Mindest-PIN-Länge des Authentifizierers anzufordern.
Eingabe
Die extensions
-Property der publicKey
muss eine minPinLength
-Property mit einem Wert von true
enthalten:
({
extensions: {
minPinLength: true,
},
});
Ausgabe
Wenn die relying party autorisiert ist, den minPinLength
-Wert zu erhalten (wenn ihre rpId
auf der autorisierten relying party-Liste des Authentifizierers vorhanden ist), enthalten die Authentifizierungsdaten eine Darstellung davon in der folgenden Form:
({ minPinLength: uint });
Wenn die relying party nicht autorisiert ist, wird die Erweiterung ignoriert und kein "minPinLength"
-Ausgabewert bereitgestellt.
payment
- Nutzbar in: Registrierung (
create()
) - Verarbeitet von: Benutzeragent
- Spezifikation: Secure Payment Confirmation
Ermöglicht es einer relying party, die Erstellung einer WebAuthn-Anmeldeinformation anzufordern, die sowohl von der relying party als auch von anderen Parteien mit Secure Payment Confirmation genutzt werden kann; siehe Using Secure Payment Confirmation.
Eingabe
Die Eingaben für die payment
-Erweiterung sind im AuthenticationExtensionsPaymentInputs-Dictionary definiert.
isPayment
-
Ein boolescher Wert, der angibt, dass die Erweiterung aktiv ist.
rpID
-
Die Relying Party-ID der verwendeten Anmeldeinformationen. Wird nur zur Authentifizierungszeit verwendet; nicht bei der Registrierung.
topOrigin
-
Der Ursprung des obersten Frames. Wird nur zur Authentifizierungszeit verwendet; nicht bei der Registrierung.
payeeName
-
Der Name des Zahlungsempfängers, falls vorhanden, der dem Benutzer angezeigt wurde. Wird nur zur Authentifizierungszeit verwendet; nicht bei der Registrierung.
payeeOrigin
-
Der Ursprung des Zahlungsempfängers, falls vorhanden, der dem Benutzer angezeigt wurde. Wird nur zur Authentifizierungszeit verwendet; nicht bei der Registrierung.
total
-
Der Betrag der Transaktion, der dem Benutzer angezeigt wurde. Wird nur zur Authentifizierungszeit verwendet; nicht bei der Registrierung. Der Betrag ist vom Typ PaymentCurrencyAmount.
instrument
-
Die Instrumentendetails, die dem Benutzer angezeigt wurden. Wird nur zur Authentifizierungszeit verwendet; nicht bei der Registrierung. Das Instrument ist vom Typ PaymentCredentialInstrument.
Ausgabe
Keine
prf
- Nutzbar in: Registrierung (
create()
) und Authentifizierung (get()
) - Verarbeitet von: Benutzeragent
- Spezifikation: Pseudo-random function extension (prf)
Ermöglicht es einer relying party, Ausgaben für entweder einen oder zwei Eingaben aus einer pseudorandomisierten Funktion (PRF) zu erhalten, die mit einer Anmeldeinformation verknüpft ist. Eine PRF ist im Wesentlichen eine random oracle – eine Funktion, die für jede gegebene Eingabe einen zufälligen Wert zurückgibt, aber immer denselben Wert für dieselbe Eingabe zurückgibt.
Die Fähigkeit, eine zufällige Zahl zu generieren, die mit der Anmeldeinformation eines Benutzers verknüpft ist, ist in einer Reihe von kryptografischen Anwendungen nützlich. Beispielsweise kann es verwendet werden, um einen symmetrischen Schlüssel zur Verschlüsselung sensibler Daten zu generieren, der nur von einem Benutzer entschlüsselt werden kann, der das Seed und den zugehörigen Authentifizierer hat. Es könnte ähnlich verwendet werden, um einen symmetrischen Schlüssel für End-to-End-Verschlüsselung zu erstellen, der mit einem Wert vom Server initialisiert wird und für diese Anmeldeinformation und Sitzung einzigartig ist.
Die Erweiterung ermöglicht es Ihnen, Pufferwerte des Typs ArrayBuffer
oder TypedArray
an den Authentifizierer zu übermitteln, der das Ergebnis der Bewertung des Wertes mit der PRF der zugehörigen Anmeldeinformation zurückgibt.
Dies kann in einer Aussage erfolgen, als Teil des Authentifizierungsablaufs – unter Angabe der Anmeldeinformation oder der Anmeldeinformationen, für die das Ergebnis ausgewertet werden soll.
Es kann auch bei der Erstellung einer Anmeldeinformation erfolgen; jedoch unterstützen weniger Authentifizierer die Generierung von Ausgaben bei der Erstellung von Anmeldeinformationen.
Eingabe
Während eines create()
-Aufrufs kann die extensions
-Property der publicKey
eine prf
-Property enthalten, die über ein eval
-Objekt mit der Eigenschaft first
und optional der Eigenschaft second
verfügt.
Diese Eigenschaften sind entweder ArrayBuffer
oder TypedArray
-Instanzen, die Werte enthalten, die an die PRF für die Anmeldeinformation übermittelt werden.
Zum Beispiel könnte die unten stehende Definition verwendet werden, wenn eine neue Anmeldeinformation erstellt wird, um einen neuen symmetrischen Schlüssel aus einem vom Server bereitgestellten Geheimnis zu erstellen.
({
extensions: {
prf: {
eval: { first: new TextEncoder().encode("Salt for new symmetric key") },
},
},
});
Die optionale second
-Eigenschaft kann verwendet werden, wenn zwei Zufallswerte für eine Anmeldeinformation erstellt werden müssen, wie in einem Workflow, in dem der Verschlüsselungsschlüssel bei jeder Sitzung gedreht wird.
Als Beispiel für einen solchen Workflow übermitteln Sie in jeder Sitzung zwei Salts: Der first
-Salt gibt einen Wert zurück, der verwendet werden kann, um die vorherigen Sitzungsdaten zu entschlüsseln, während der second
-Salt einen Wert zurückgibt, der verwendet werden kann, um die Sitzungsdaten dieser Sitzung zu verschlüsseln.
In den nachfolgenden Sitzungen wird der second
-Salt an die Position des first
-Salts verschoben, sodass die Lebensdauer, in der ein bestimmter Salt nützlich kompromittiert werden kann, begrenzt ist.
{
extensions: {
prf: {
eval: {
first: currentSessionKey /* salt for current session */,
second: nextSessionKey /* salt for next session */,
},
},
},
};
Der create()
-Aufruf kann mit folgenden Ausnahmen abgelehnt werden:
NotSupportedError
DomException
- Der Schlüssel
evalByCredential
ist imeval
-Objekt vorhanden.
- Der Schlüssel
Beachten Sie, dass die Auswertung einer PRF bei der Erstellung einer Anmeldeinformation möglicherweise nicht unterstützt wird, und dies würde in der Ausgabe gemeldet werden. Sie können immer noch versuchen, die PRF in einer Aussage zu evaluieren, wie unten gezeigt.
Während eines get()
-Aufrufs kann die extensions
-Property der publicKey
eine prf
-Property mit der Untereigenschaft evalByCredential
enthalten.
Dies ist ein Objekt, das Base64 URL-codierte Anmeldeinformations-IDs auf Bewertungobjekte mit der im obigen Beispiel gezeigten Form abbildet.
Mit anderen Worten, dies ermöglicht Ihnen, Werte für verschiedene Anmeldeinformationen zu evaluieren.
{
extensions: {
prf: {
evalByCredential: {"<credentialId>": {first: bufferOne, second: bufferTwo}, ..., "<credentialId>": {first: anotherBufferOne, second: anotherBufferTwo} }
},
},
};
Der get()
-Aufruf kann mit folgenden Ausnahmen abgelehnt werden:
NotSupportedError
DomException
-
Wenn
eval
dasprf
-Objekt ist, oder wennallowCredentials
leer ist, wennevalByCredential
nicht leer ist. SyntaxError
DomException
-
Jeder Schlüssel in
evalByCredential
ist die leere Zeichenfolge oder keine gültige Base64-URL-Codierung oder stimmt nicht mit der ID eines Elements inpublicKey.allowCredentials
überein.
Ausgabe
Ein erfolgreicher create()
-Aufruf liefert die folgende Erweiterungsausgabe, wenn die registrierte Anmeldeinformation die Verwendung der PRF bei der Erstellung von Anmeldeinformationen unterstützt.
{
prf: {
enabled: true, // PRF can be used when creating credentials.
results: {first: outputBuffer1, second: outputBuffer2}
},
};
Die enabled
-Property gibt an, ob die PRF bei der Erstellung von Anmeldeinformationen verwendet werden kann.
Die first
und second
Properties enthalten das Ergebnis der Auswertung von first
und second
auf der Eingabe, und second
wird weggelassen, wenn die entsprechende Eingabe nicht spezifiziert wurde.
Wenn der Authentifizierer die Verwendung der PRF bei der Erstellung nicht unterstützt, sieht die Ausgabe von create()
so aus:
{
prf: {
enabled: false, // PRF cannot be used when creating credentials.
},
};
Ein get()
gibt ein gleiches prf
-Objekt mit der gleichen Struktur wie create()
zurück, mit Ausnahme, dass es den enabled
-Schlüssel weglässt.
Das Objekt enthält PRF-Werte, die den Eingaben für die vom Benutzer ausgewählte Anmeldeinformation entsprechen.
{
prf: {
results: {first: outputBuffer1, second: outputBuffer2}
},
};
Beachten Sie, dass enabled
nur als Ausgabe für create()
vorhanden ist und angibt, ob die PRF vom Authentifizierer unterstützt wird, wenn eine Anmeldeinformation erstellt wird.
Wenn der Authentifizierer die PRF überhaupt nicht unterstützt, sieht das Ergebnis für den get()
-Aufruf so aus:
{
prf: {},
};
Spezifikationen
Specification |
---|
Web Authentication: An API for accessing Public Key Credentials - Level 3 # sctn-defined-extensions |
Unknown specification # sctn-defined-extensions |
WebAuthn-Erweiterungen sind an mehreren Stellen spezifiziert. IANA's WebAuthn-Erweiterungs-Identifikatoren bietet ein Register aller Erweiterungen, aber beachten Sie, dass einige der Erweiterungen veraltet sein können.
Browser-Kompatibilität
Die Kompatibilitätsdaten für WebAuthn-Erweiterungen wurden in zwei Tabellen unterteilt – Erweiterungen, die während der Anmeldedatenregistrierung (create()
) verwendet werden können, und Erweiterungen, die während der Authentifizierung (get()
) verwendet werden können. Einige Erweiterungen sind während beider Vorgänge nutzbar.