Require reauthentication before adding a passkey or setting a password - #68522
Open
rolandVi wants to merge 2 commits into
Open
Require reauthentication before adding a passkey or setting a password#68522rolandVi wants to merge 2 commits into
rolandVi wants to merge 2 commits into
Conversation
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
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.
In the Blazor template with Individual Accounts, adding a passkey now asks you to confirm who you
are first, with a credential the account already has.
What changed
The confirmation is a shared
ReauthenticationPromptcomponent that offers whatever the accountactually holds: its password, one of its existing passkeys, or a re-challenge of a linked external
login. Confirming writes a data-protected cookie holding the user id and the current security stamp,
so changing the password or signing out everywhere invalidates it.
/Account/PasskeyCreationOptionsmoves into the/Managegroup, which requires authorization, andnow refuses to hand out options without that marker. Left where it was, a cookie holder could fetch
options straight from it and skip the page entirely.
Confirming with a passkey goes through a new options endpoint that takes no username, and the
handler checks the asserted passkey belongs to the account that is already signed in.
SetPasswordtakes the same confirmation. It only gates on whether the account has a password yet,so otherwise a cookie holder could set one and immediately use it to pass the new gate.
Resolves #66865.