Add passkeys to ASP.NET Core Identity #62112

MackinnonBuck · 2025-05-27T06:32:18Z

Add passkeys to ASP.NET Core Identity

This PR adds passkey support to ASP.NET Core Identity.

Description

Following is a summary of the changes in this PR:

Updated the Blazor Web App template to support passkey management and login
Added passkey (WebAuthn) support to ASP.NET Core Identity:
- New passkey store abstractions with updated store implementations in Microsoft.AspNetCore.Identity.EntityFrameworkCore
- New passkey abstractions for attestation and assertion
- Extensibility points in the default passkey handler for e.g., attestation statement validation
- Support for all cryptographic algorithms tested by the FIDO conformance testing tool, except EdDSA.
- New APIs in SignInManager and UserManager for passkey management and sign in
Added a sample project that can be run against the FIDO conformance testing tool

Note that the goal of this PR is to add support for passkey authentication in ASP.NET Core Identity. While it implements core WebAuthn functionality, it does not provide a complete and general-purpose WebAuthn/FIDO2 library. The public API surface is limited in order to enable long-term stability of the feature. Targeted extensibility points were added to enable functionality not implemented by default, most notably attestation statement validation. This allows the use of third-party libraries to fill the missing gaps, when desired. Community feedback may result in additional extensibility APIs being added in the future.

This PR includes E2E tests validating that a passkey can be registered and used for logging in. I'll add unit tests after we agree on the design to avoid churn.

Fixes #53467

JamesNK · 2025-05-27T08:40:08Z

FYI I have a PR adding metrics to identity here: #62078. Whoever merges second will need to react and add counters and tags for passkey signins.

Copilot

Pull Request Overview

This PR adds support for passkeys to ASP.NET Core Identity by extending the existing identity stores and sign‐in flows. Key changes include:

Introducing new generic abstractions and methods for managing passkeys in both UserStore and UserOnlyStore.
Updating IdentityUserContext model building to support passkeys under Identity Schema Version 3.
Extending SignInManager with new APIs for passkey sign in and for configuring/retrieving passkey creation and request options.

Reviewed Changes

Copilot reviewed 111 out of 111 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Identity/EntityFrameworkCore/src/UserStore.cs	Added a new generic UserStore overload and methods to create, find, update, and remove user passkeys.
src/Identity/EntityFrameworkCore/src/UserOnlyStore.cs	Extended the store for users without roles to support passkey operations along with checks for DB support.
src/Identity/EntityFrameworkCore/src/IdentityUserContext.cs	Modified OnModelCreating to include a new entity for passkeys when using Identity Schema Version 3.
src/Identity/Core/src/SignInManager.cs	Introduced new methods for passkey sign in and configuration of passkey creation/request options.
PublicAPI.Unshipped.txt and build files	Updated the public API surface and project configuration to expose passkey-related features.

src/Identity/Core/src/SignInManager.cs

MackinnonBuck

Some comments to help with reviewing.

src/Identity/Extensions.Core/src/IPasskeyRequestContextProvider.cs

src/Identity/Core/src/IdentityBuilderExtensions.cs

MackinnonBuck · 2025-05-27T21:05:38Z

src/Identity/Extensions.Core/src/IPasskeyOriginValidator.cs

+public interface IPasskeyOriginValidator
+{
+    /// <summary>
+    /// Determines whether the specified origin is valid for passkey operations.
+    /// </summary>
+    /// <param name="originInfo">Information about the passkey's origin.</param>
+    /// <returns><c>true</c> if the origin is valid; otherwise, <c>false</c>.</returns>
+    bool IsValidOrigin(PasskeyOriginInfo originInfo);
+}


This interface exists because the meaning of a "valid origin" can vary widely between applications. See https://www.w3.org/TR/webauthn-3/#sctn-validating-origin.

MackinnonBuck · 2025-05-27T21:06:47Z

src/Identity/Extensions.Core/src/IUserPasskeyStore.cs

+    /// <summary>
+    /// Adds a new passkey credential in the store for the specified <paramref name="user"/>,
+    /// or updates an existing passkey.
+    /// </summary>
+    /// <param name="user">The user to create the passkey credential for.</param>
+    /// <param name="passkey">The passkey to add.</param>
+    /// <param name="cancellationToken">The <see cref="CancellationToken"/> used to propagate notifications that the operation should be canceled.</param>
+    /// <returns>The <see cref="Task"/> that represents the asynchronous operation.</returns>
+    Task SetPasskeyAsync(TUser user, UserPasskeyInfo passkey, CancellationToken cancellationToken);


Considering splitting this out into AddPasskeyAsync and UpdatePasskeyAsync.

MackinnonBuck · 2025-05-27T21:13:48Z

src/Identity/Extensions.Core/src/PasskeyCreationOptions.cs

+    /// <summary>
+    /// Gets the JSON representation of the options.
+    /// </summary>
+    /// <remarks>
+    /// The structure of the JSON string matches the description in the WebAuthn specification.
+    /// See <see href="https://www.w3.org/TR/webauthn-3/#dictdef-publickeycredentialcreationoptionsjson"/>.
+    /// </remarks>
+    public string AsJson()
+        => _optionsJson;


This PR currently just exposes the credential creation/request options as a JSON string rather than returning a strongly-typed object. That way we're not locked into making the entirety of the Passkeys/ folder public. In the future, if we wanted to e.g., write a hand-crafted JSON writer that constructed a string without first building a .NET representation, we could do that.

Making this method virtual would allow users to override its logic if needed.

MackinnonBuck · 2025-05-27T21:17:16Z

src/Identity/Extensions.Stores/src/IdentityUserPasskey.cs

+    /// <summary>
+    /// Gets or sets whether the passkey has a verified user.
+    /// </summary>
+    public virtual bool IsUserVerified { get; set; }
+
+    /// <summary>
+    /// Gets or sets whether the passkey is eligible for backup.
+    /// </summary>
+    public virtual bool IsBackupEligible { get; set; }
+
+    /// <summary>
+    /// Gets or sets whether the passkey is currently backed up.
+    /// </summary>
+    public virtual bool IsBackedUp { get; set; }


These flags are all present on the authenticator data flags. We could just store the flags byte directly so that we don't introduce another schema change in the future, should we find ourselves wanting to store more flags.

These flags (per the specification) must be persisted and validated during authentication processing for previously created passkeys.

The specification states in the Credential Backup State section:

"The value of the BE flag is set during authenticatorMakeCredential operation and MUST NOT change."

This means:

The BE (Backup Eligible) flag must remain unchanged after Passkey creation.

If BE was initially 0 (false), the BS (Backup State) flag must never be 1 (true).

Storing these flags in binary form would be impractical. The current implementation (keeping them as separate values) provides the right balance of correctness and usability.

Thanks for the feedback, @vanbukin.

Storing these flags in binary form would be impractical. The current implementation (keeping them as separate values) provides the right balance of correctness and usability.

I agree it's more usable to keep them as separate properties. The main reason for my initial suggestion was to avoid cases where spec changes require additional flags to be stored, incurring an update to this model and a migration in customers' apps.

For example, the BS and BE flags weren't defined in the WebAuthn Level 2 spec, but were added in the Level 3 spec. A similar adjustment could theoretically be made in the future.

MackinnonBuck · 2025-05-27T21:28:29Z

.../content/BlazorWeb-CSharp/BlazorWeb-CSharp/Components/Account/Shared/PasskeyHandler.razor.js

+async function createCredential(optionsJSON) {
+    // See: https://www.w3.org/TR/webauthn-2/#sctn-registering-a-new-credential
+
+    // 1. Let options be a new PublicKeyCredentialCreationOptions structure configured to
+    //    the Relying Party’s needs for the ceremony.
+    // See: https://www.w3.org/TR/webauthn-3/#dom-publickeycredential-parsecreationoptionsfromjson
+    const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON);
+
+    // 2. Call navigator.credentials.create() and pass options as the publicKey option.
+    //    Let credential be the result of the successfully resolved promise.
+    //    If the promise is rejected, abort the ceremony with a user-visible error,
+    //    or otherwise guide the user experience as might be determinable from the
+    //    context available in the rejected promise.
+    const credential = await navigator.credentials.create({ publicKey: options });
+
+    // 3. Let response be credential.response. If response is not an instance of
+    //    AuthenticatorAttestationResponse, abort the ceremony with a user-visible error.
+    if (!(credential?.response instanceof AuthenticatorAttestationResponse)) {
+        throw new Error('The authenticator failed to provide a valid credential.');
+    }
+
+    // Continue the ceremony on the server.
+    // See: https://www.w3.org/TR/webauthn-3/#dom-publickeycredential-tojson
+    return JSON.stringify(credential);
+}


We could move this code to a package, but it's so small that I think it's safe to include it in the template.
However, I'm considering changing the options parameter here to represent the top-level object passed to the navigator.credentials.create() function instead of representing the publicKey property. That's because the WebAuthn level 3 spec references another top-level property, mediation in the ceremony, and we might want a way to configure it (and other not-yet-introduced properties) in the future.

Also, this script assumes it's loaded as part of a full page navigation, not an enhanced navigation. This strategy currently works because the script gets rendered as a result of a non-enhanced form post.

MackinnonBuck · 2025-05-27T21:29:44Z

src/Identity/Extensions.Core/src/Passkeys/PublicKeyCredentialParameters.cs

+        [
+            new(COSEAlgorithmIdentifier.ES256),
+            new(COSEAlgorithmIdentifier.PS256),
+            new(COSEAlgorithmIdentifier.ES384),
+            new(COSEAlgorithmIdentifier.PS384),
+            new(COSEAlgorithmIdentifier.PS512),
+            new(COSEAlgorithmIdentifier.RS256),
+            new(COSEAlgorithmIdentifier.ES512),
+            new(COSEAlgorithmIdentifier.RS384),
+            new(COSEAlgorithmIdentifier.RS512),
+        ];


This list does not include RS1, even though the FIDO conformance testing tool checks for it. Maybe we should make this list configurable.

I imagine RS1 is RSASHA1, so I think it's ok to leave it out, but @blowdart might care.

mguinness · 2025-06-01T03:42:52Z

Is there any provision for passkey integration into identity API endpoints via IdentityApiEndpointRouteBuilderExtensions?

javiercn

Some initial review feedback.

I need to do a more detailed pass, specially over the crypto stuff.

Overall looks good, and I'm happy to see this landing as it is a great improvement for security. The main pieces of feedback I have are:

Layering -> I think a lot of this code should go into Identity directly rather than Core.
UserManager vs SignInManager: Some of the code might fit better in SignInManager, specially if it requires access to HttpContext (or you are accessing it behind an abstraction).
- Maybe collect the HttpContext based info you need in SignInManager and call UserManager with it.
Json strings through the API or S.T.J types on the DTOs. My understanding is that part of it is to avoid serializing/deserializing things and making additional types public.
- An option here could be to create an "opaque" type that contains the Json data. Maybe with a GetRawData or something like that which returns the original JSON string. That way in the future you can add fields to the type if you want/need to and use those directly over the string, and anyone who needs access to the data, can get the string and deserialize it. (which is no different than what they have to do today, isn't it?)

javiercn · 2025-05-31T18:00:29Z

...tes/content/BlazorWeb-CSharp/BlazorWeb-CSharp/Components/Account/Shared/PasskeyHandler.razor

+@using BlazorWeb_CSharp.Data
+@using Microsoft.AspNetCore.Authentication
+@using Microsoft.AspNetCore.Identity
+
+<form id="passkey-response-form" @formname="passkey-response" @onsubmit="OnSubmitAsync" method="post">
+    <AntiforgeryToken />
+    <input id="passkey-response" type="hidden" name="@(nameof(ResponseJson))" />
+    <input id="passkey-error" type="hidden" name="@(nameof(Error))" />
+</form>
+
+@if (options is not null)
+{
+    <script type="application/json" id="passkey-options">@((MarkupString)options)</script>
+    <script src="./Components/Account/Shared/PasskeyHandler.razor.js" data-action="@action"></script>
+}
+
+@code {
+    private string? action;
+    private string? options;
+
+    [Parameter]
+    public string? CurrentCreationOptions { get; set; }
+
+    [Parameter]
+    public string? CurrentRequestOptions { get; set; }
+
+    [Parameter]
+    [EditorRequired]
+    public EventCallback<string> OnResponse { get; set; }
+
+    [Parameter]
+    [EditorRequired]
+    public EventCallback<string?> OnError { get; set; }
+
+    [SupplyParameterFromForm]
+    private string? ResponseJson { get; set; }
+
+    [SupplyParameterFromForm]
+    private string? Error { get; set; }
+
+    [CascadingParameter]
+    private HttpContext HttpContext { get; set; } = default!;
+
+    protected override async Task OnInitializedAsync()
+    {
+        if (HttpMethods.IsGet(HttpContext.Request.Method))
+        {
+            // Clear the existing two factor cookie to ensure a clean ceremony
+            await HttpContext.SignOutAsync(IdentityConstants.TwoFactorUserIdScheme);
+        }
+    }
+
+    protected override void OnParametersSet()
+    {
+        (options, action) = (CurrentCreationOptions, CurrentRequestOptions) switch
+        {
+            (null, null) => (null, null),
+            (var createOptions, null) => (createOptions, "create"),
+            (null, var requestOptions) => (requestOptions, "get"),
+            (not null, not null) => throw new InvalidOperationException(
+                $"Only one of '{nameof(CurrentCreationOptions)}' and '{nameof(CurrentRequestOptions)}' should be specified."),
+        };
+    }
+
+    private async Task OnSubmitAsync()
+    {
+        if (ResponseJson is { Length: > 0 } responseJson)
+        {
+            await OnResponse.InvokeAsync(responseJson);
+        }
+        else
+        {
+            await OnError.InvokeAsync(Error);
+        }
+    }
+}


Could this be a minimal API endpoint?

My initial prototype actually did have this as a minimal API endpoint, with more of the WebAuthn ceremony defined in JS. Rewriting it to be more Razor-centric was maybe a bit of a "grass is greener" move by me. The initial, prototype JS logic fairly intertwined with the UI, since it had to, e.g., read form fields and manually insert error messages into the DOM when failures occur. I was partly concerned that someone could modify the Razor code without expecting hidden JS to depend on things like form field names, but also thought that it was a better separation of concerns to have Razor handle the UI and JS handle only the parts that must be JS (like calling navigator.credentials.create()).

However, after implementing the Razor-based approach and receiving this feedback, I can see that performing this handshake as a series of renders makes the logical sequence of events less aligned with how the code looks. So I'm fine with considering moving back to the old strategy.

Another option is to make the passkey login and management pages interactive, although if we plan to make similar UI changes to Microsoft.AspNetCore.Identity.UI, then we'd need a JS-based implementation anyway.

Update: I've reimplemented the passkey functionality in the template to invoke a minimal API endpoint rather than doing a sequence of form submissions.

javiercn · 2025-05-31T18:08:48Z

...jectTemplates/content/BlazorWeb-CSharp/BlazorWeb-CSharp/Components/Account/Pages/Login.razor

+            var user = Input.Email is { Length: > 0 } email
+                ? await UserManager.FindByEmailAsync(email)
+                : null;
+
+            var passkeyRequestArgs = new PasskeyRequestArgs<ApplicationUser>
+            {
+                User = user,
+            };
+            var options = await SignInManager.ConfigurePasskeyRequestOptionsAsync(passkeyRequestArgs);


Might make sense for ConfigurePasskeyRequestOptionsAsync to take in the email as a separate parameter and perform this bit of logic internally to set the user.

That way you avoid having to inject the UserManager in addition to the sign in manager.

Identity doesn't require that users have an email though, right? Or is the suggestion to add a convenience method that wraps the one accepting a TUser directly?

javiercn · 2025-05-31T18:11:13Z

...jectTemplates/content/BlazorWeb-CSharp/BlazorWeb-CSharp/Components/Account/Pages/Login.razor

@@ -16,8 +17,9 @@
 <div class="row">
    <div class="col-lg-6">
        <section>
+            <PasskeyHandler CurrentRequestOptions="@currentPasskeyRequestOptions" OnResponse="LoginUserWithPasskey" OnError="SetPasskeyError" />


Is there a reason why we want to do this dance through .razor as opposed to making the handler a minimal API and handle the entire process via JS?

See comment here. Happy to consider changing the implementation to be more JS-centric.

Update: I've reimplemented the passkey functionality in the template to invoke a minimal API endpoint rather than doing a sequence of form submissions.

src/Identity/Core/src/SignInManager.cs

javiercn · 2025-06-02T12:31:42Z

src/Identity/Extensions.Core/src/IPasskeyHandler.cs

+    /// <param name="originalOptionsJson">The JSON representation of the original passkey creation options provided to the browser.</param>
+    /// <param name="userManager">The <see cref="UserManager{TUser}"/> to retrieve user information from.</param>
+    /// <returns>A task object representing the asynchronous operation containing the <see cref="PasskeyAssertionResult{TUser}"/>.</returns>
+    Task<PasskeyAssertionResult<TUser>> PerformAssertionAsync(TUser? user, string credentialJson, string originalOptionsJson, UserManager<TUser> userManager);


For all these APIs, dealing in the serialized JSON string feels "strange". I'm not 100% sure how big these strings are, but I would think it makes more sense for these payloads to get deserialized into DTOs and passed in as objects rather than having the guts of Identity handle the serialization concerns.

The main reason I did it this way is to avoid exposing the details of the WebAuthn spec as public C# API. But I agree it feels unusual. Maybe we could do something similar to the PasskeyCreationOptions type added in this PR, which exposes a small number of strongly-typed properties but has a method to get the underlying JSON representation.

src/Identity/Extensions.Core/src/IPasskeyRequestContextProvider.cs

javiercn · 2025-06-02T12:44:57Z

src/Identity/Extensions.Core/src/PasskeyRequestArgs.cs

+    /// <remarks>
+    /// See <see href="https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialrequestoptions-extensions"/>.
+    /// </remarks>
+    public JsonElement? Extensions { get; set; }


Using JsonElement here is a bit "strange", is there another type that could be used instead? (IDictionary<string,object>) or similar?

Not sure it's possible - this property gets forwarded to a PublicKeyCredentialRequestOptions object, whose sole purpose is to get serialized into a JSON payload that gets passed to the JavaScript navigator.credentials.get() method.

This JSON serialization happens internally within Identity and uses the JSON source generator (the customer doesn't get to specify their own JsonSerializerOptions because the serialization mechanism is an internal implementation detail).

So, if the Extensions property was an IDictionary<string, object>, our implementation would throw for any dictionary values we haven't anticipated in the IdentityJsonSerializerContext. Whereas, the current approach allows the developer to either create a JsonElement directly or serialize another .NET type into one via JsonSerializer.SerializeToElement(), where they can pass their own JsonSerializerOptions.

All that said, there might be a better way of handling this than JsonElement that I haven't thought of.

I don't think JsonElement is that strange. We've been using it a lot in the MCP cshar-sdk repo for things like InputSchema. If the goal is to serialize/deserialize extensions as JSON, IDictionary<string,object> feels inappropriate because the object would probably just JsonElements most of the time anyway.

This does prevent us from switching to a different JSON library in the future or using something other than JSON for this, but I highly doubt we'd switch from System.Text.Json, and it appears the webauthn standard requires JSON for extensions.

@eiriktsarpalis Do you think JsonElement makes sense?

Whereas, the current approach allows the developer to either create a JsonElement directly

You can't just create a JsonElement. But instead, you need to get a JsonDocument and get the JsonElement out of that.

Would using JsonNode work better here if we expect people to create these directly?

javiercn · 2025-06-02T12:49:03Z

src/Identity/Extensions.Core/src/Passkeys/AttestationObject.cs

+{
+    public string Fmt => fmt;
+
+    public ReadOnlyMemory<byte> AttStmt => attStmt;


nit: I would avoid the abbreviations

The property names match https://www.w3.org/TR/webauthn-3/#attestation-object. I aimed to have as close to a 1:1 mapping between the WebAuthn-related models and the types described in the spec as possible, but if we think it's clearer to expand these names, I'd be fine doing so 🙂

src/Identity/Extensions.Core/src/Passkeys/BufferSourceJsonConverter.cs

mguinness · 2025-06-02T15:56:29Z

...jectTemplates/content/BlazorWeb-CSharp/BlazorWeb-CSharp/Components/Account/Pages/Login.razor

Consider using Authenticate with a passkey through form autofill with autocomplete="username webauthn" for a better user experience.

halter73

Should we make it possible to register with just a passkey and not a password with the Blazor project template? I'm fine if we do this as a follow up.

I'm also a fan of the layering adjustment that Javier suggested to move the HttpContext-related stuff up to the AspNetCore package and moving more stuff from UserManager to the SignInManager.

src/ProjectTemplates/test/Templates.Blazor.Tests/BlazorTemplateTest.cs

src/ProjectTemplates/test/Templates.Blazor.Tests/BlazorWebTemplateTest.cs

halter73 · 2025-06-05T15:30:50Z

src/Identity/EntityFrameworkCore/src/PublicAPI.Unshipped.txt

+*REMOVED*virtual Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityUserContext<TUser, TKey, TUserClaim, TUserLogin, TUserToken>.UserTokens.get -> Microsoft.EntityFrameworkCore.DbSet<TUserToken!>!
+*REMOVED*virtual Microsoft.AspNetCore.Identity.EntityFrameworkCore.IdentityUserContext<TUser, TKey, TUserClaim, TUserLogin, TUserToken>.UserTokens.set -> void
+*REMOVED*virtual Microsoft.AspNetCore.Identity.EntityFrameworkCore.UserOnlyStore<TUser, TContext, TKey, TUserClaim, TUserLogin, TUserToken>.Context.get -> TContext!
+*REMOVED*virtual Microsoft.AspNetCore.Identity.EntityFrameworkCore.UserStore<TUser, TRole, TContext, TKey, TUserClaim, TUserRole, TUserLogin, TUserToken, TRoleClaim>.Context.get -> TContext!


Are these removals just because our API checking tool doesn't know that these members are now inherited? Also, do you think we're ready for an API proposal issue? You might be able to use AI to generate one from this PR.

I think it's okay to merge the PR ahead of API review as long as we go through the process. Keeping such a large PR open for a long time can make it harder to keep track of what's changed and review although separate commits can help with that.

Are these removals just because our API checking tool doesn't know that these members are now inherited?

Yes, that's exactly right.

I think it's okay to merge the PR ahead of API review as long as we go through the process. Keeping such a large PR open for a long time can make it harder to keep track of what's changed and review although separate commits can help with that.

Totally agreed. I'll put together an API proposal issue after I complete a few more pending updates to this PR.

halter73 · 2025-06-05T15:52:27Z

src/Identity/Extensions.Core/src/PasskeyExceptionExtensions.cs

+
+internal static class PasskeyExceptionExtensions
+{
+    extension(PasskeyException)


Cool use of the new syntax, but why not just make these normal internal static methods? Also, would application level code ever need to do a runtime check of the kind of PasskeyException? Would it make sense for there to be an PasskeyExceptionReason enum or something like that? The names of these methods seem like they could be good enum values.

Cool use of the new syntax, but why not just make these normal internal static methods?

I thought it might be better to separate out these helper methods from the core PasskeyException declaration, but it was also an excuse to use static extension members :) I'm fine with moving them back if that's preferable.

Also, would application level code ever need to do a runtime check of the kind of PasskeyException? Would it make sense for there to be an PasskeyExceptionReason enum or something like that? The names of these methods seem like they could be good enum values.

Hm, maybe. We do something similar in IdentityErrorDescriber. I'm just now sure how common it'll be to programmatically react to different passkey validation failures. It might be useful for metrics, though. For example, if the server keeps rejecting credentials and the developer wants to find out why, reporting the exception "reason" might be helpful? I wonder if we should consider this as a potential follow-up item.

halter73 · 2025-06-05T15:54:07Z

src/Identity/Extensions.Core/src/PasskeyExceptionExtensions.cs

+        public static PasskeyException InvalidCredentialType(string expectedType, string actualType)
+            => new($"Expected credential type '{expectedType}', got '{actualType}'.");


Nit:

Suggested change

public static PasskeyException InvalidCredentialType(string expectedType, string actualType)

=> new($"Expected credential type '{expectedType}', got '{actualType}'.");

[DoesNotReturn]

public static void ThrowInvalidCredentialType(string expectedType, string actualType)

=> throw new($"Expected credential type '{expectedType}', got '{actualType}'.");

It looks like in 99% or cases we're throwing immediately, and this is a bit more conventional.

I had that initially, but unfortunately [DoesNotReturn] isn't sufficient enough to remove throw null; in all cases :(

MackinnonBuck · 2025-06-05T22:08:15Z

src/Identity/Core/src/SignInManager.cs

+        ArgumentNullException.ThrowIfNull(creationArgs);
+
+        var excludeCredentials = await GetExcludeCredentialsAsync();
+        var serverDomain = Options.Passkey.ServerDomain ?? Context.Request.Host.Host;


In a previous iteration of this PR, the computed domain was configurable via custom IPasskeyRequestContextProvider implementation. I've since removed that abstraction because it became less necessary after moving most of the passkey implementation to the Microsoft.AspNetCore.Identity package. Curious if others think we need to allow customization of the "fallback" logic here in the case of Options.Passkey.ServerDomain not being specified.

...harp/BlazorWeb-CSharp/Components/Account/IdentityComponentsEndpointRouteBuilderExtensions.cs

src/Identity/Core/src/Passkeys/BufferSourceJsonConverter.cs

Initial commit

01104ac

github-actions bot added the area-identity Includes: Identity and providers label May 27, 2025

MackinnonBuck added 2 commits May 27, 2025 10:56

Remove extra entry in Version.Details.xml

8294e9e

Fix Program.Main.cs

725a304

MackinnonBuck requested a review from Copilot May 27, 2025 20:31

Copilot AI reviewed May 27, 2025

View reviewed changes

src/Identity/Core/src/SignInManager.cs Show resolved Hide resolved

src/Identity/Core/src/SignInManager.cs Show resolved Hide resolved

MackinnonBuck commented May 27, 2025

View reviewed changes

MackinnonBuck added 2 commits May 27, 2025 15:31

Fix failing tests

f86515f

Merge remote-tracking branch 'origin/main' into mbuck/passkeys

f828930

MackinnonBuck marked this pull request as ready for review May 28, 2025 22:37

MackinnonBuck requested review from halter73, a team and wtgodbe as code owners May 28, 2025 22:38

javiercn reviewed Jun 2, 2025

View reviewed changes

mguinness reviewed Jun 2, 2025

View reviewed changes

MackinnonBuck added 3 commits June 3, 2025 14:49

Add passkey sample app + E2E tests

ee5e007

Correctly specify transports in generated credential options

e23320c

Merge branch 'main' into mbuck/passkeys

32d3f5f

build-analysis bot mentioned this pull request Jun 4, 2025

Known Build Error: error : Cannot create a file when that file already exists. #61178

Open

MackinnonBuck added 2 commits June 5, 2025 07:20

Merge branch 'main' into mbuck/passkeys

b07c980

Undo changes to Components.slnf

5d3b864

halter73 reviewed Jun 5, 2025

View reviewed changes

Move core passkey implementation to Microsoft.AspNetCore.Identity

af27faf

MackinnonBuck commented Jun 5, 2025

View reviewed changes

MackinnonBuck added 3 commits June 5, 2025 20:25

Update Passkeys.razor

65e6a37

PR feedback

bb187c7

Update template passkey functionality

d178068

mguinness reviewed Jun 7, 2025

View reviewed changes

...harp/BlazorWeb-CSharp/Components/Account/IdentityComponentsEndpointRouteBuilderExtensions.cs Outdated Show resolved Hide resolved

PR feedback

331b5f6

eerhardt reviewed Jun 9, 2025

View reviewed changes

src/Identity/Core/src/Passkeys/BufferSourceJsonConverter.cs Show resolved Hide resolved

build-analysis bot mentioned this pull request Jun 9, 2025

NuGet failing with Response status code does not indicate success: 503 (Service Unavailable) dotnet/arcade#11723

Open

5 tasks

MackinnonBuck added 2 commits June 9, 2025 14:05

PR feedback

beecc32

Remove PasskeyRequestContext

2636c5e

MackinnonBuck mentioned this pull request Jun 9, 2025

[API Proposal] Passkeys in ASP.NET Core Identity #62287

Open

		public static PasskeyException InvalidCredentialType(string expectedType, string actualType)
		=> new($"Expected credential type '{expectedType}', got '{actualType}'.");

-        public static PasskeyException InvalidCredentialType(string expectedType, string actualType)
-            => new($"Expected credential type '{expectedType}', got '{actualType}'.");
+        [DoesNotReturn]
+        public static void ThrowInvalidCredentialType(string expectedType, string actualType)
+            => throw new($"Expected credential type '{expectedType}', got '{actualType}'.");

Add passkeys to ASP.NET Core Identity #62112

Are you sure you want to change the base?

Add passkeys to ASP.NET Core Identity #62112

Conversation

MackinnonBuck commented May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add passkeys to ASP.NET Core Identity

Description

Uh oh!

JamesNK commented May 27, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

Uh oh!

MackinnonBuck left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MackinnonBuck May 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mguinness commented Jun 1, 2025

Uh oh!

javiercn left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

MackinnonBuck commented May 27, 2025 •

edited

Loading

MackinnonBuck May 27, 2025 •

edited

Loading

MackinnonBuck May 27, 2025 •

edited

Loading

mguinness Jun 2, 2025 •

edited

Loading

halter73 Jun 5, 2025 •

edited

Loading