feat(webauthn): support appid and appidExclude extensions#204
Open
AlfioEmanueleFresta wants to merge 3 commits into
Open
feat(webauthn): support appid and appidExclude extensions#204AlfioEmanueleFresta wants to merge 3 commits into
AlfioEmanueleFresta wants to merge 3 commits into
Conversation
AlfioEmanueleFresta
force-pushed
the
feat/webauthn-appid-extensions
branch
from
7360190 to
c838f4b
Compare
Per WebAuthn L3 sections 10.1 and 10.2, RPs can opt into using legacy U2F AppID strings for assertion and registration ceremonies. This adds the wire-level IDL fields so the JSON parser accepts them and the response serializer can surface the appid extension output.
…grade Adds appid to GetAssertionRequestExtensions and routes it through try_downgrade(): when set, the U2F sign path emits a paired SignRequest keyed under SHA-256(appid) for each allow-list entry, in addition to the rpId-derived request. This makes legacy U2F-keyed credentials reachable through the WebAuthn API. Also adds the appid output field to GetAssertionResponseUnsignedExtensions and a basic same-site sanity check on the input URL.
… appid in U2F output Adds a ctap2_preflight_with_appid helper that tests each excludeList entry under both the rpId-derived and the appidExclude-derived application parameter (WebAuthn L3 sec 10.2), preventing duplicate registration of legacy U2F-keyed credentials. On the U2F downgrade get_assertion path, surface the FIDO AppID extension output (clientExtensionResults.appid) based on which of the paired SignRequests matched.
AlfioEmanueleFresta
force-pushed
the
feat/webauthn-appid-extensions
branch
from
c838f4b to
f4aa890
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds the WebAuthn
appid(assertion) andappidExclude(registration) extensions, which let a Relying Party reuse its legacy FIDO U2F-keyed credentials inside the WebAuthn API.Background
FIDO U2F credentials were registered with an "AppID", a string (typically an
https://URL) that the authenticator hashed with SHA-256 to derive the per-application key. When an RP migrates from U2F to WebAuthn, its existing user accounts have credentials keyed under that legacy AppID, not under the newrp.id. To keep those credentials usable, WebAuthn defines two extensions:appid(assertion only): the RP supplies its legacy AppID and the platform triesSHA-256(appid)as the application parameter alongsideSHA-256(rpId).appidExclude(registration only): preflight tests theexcludeListagainstSHA-256(appidExclude)in addition toSHA-256(rpId), so the RP can prevent duplicate registration when a legacy U2F-keyed credential already exists.Without these extensions, libwebauthn always derives the U2F application parameter from
rp.id, making any legacy-AppID credential unreachable through the WebAuthn API.Changes
appidandappidExcludeaccepted on the request side;appid: boolemitted on the response side (clientExtensionResults.appid).SignRequestkeyed underSHA-256(appid)per allow-list entry, paired with theSHA-256(rpId)variant.clientExtensionResults.appidreflects which one matched.excludeListentries against bothSHA-256(rpId)andSHA-256(appidExclude), so duplicate-prevention works against legacy-keyed credentials.appidstring (must be a non-emptyhttps://URL).appid, validation rejection of non-https AppIDs, preflight detection of a legacy-keyed credential whenappid_excludeis supplied.Deferred (worth a follow-up)
appidagainstrpIdper WebAuthn L3 sec. 10.1.1.0x07check-only) that would also reduce the per-attempt cost ofappid/appidExcludeon U2F-only authenticators.References
appid): https://www.w3.org/TR/webauthn-3/#sctn-appid-extensionappidExclude): https://www.w3.org/TR/webauthn-3/#sctn-appid-exclude-extensionappid): https://www.w3.org/TR/webauthn-1/#sctn-appid-extension