Skip to content

v3.4.0

Choose a tag to compare

View all tags
@madeyoga madeyoga released this 12 Oct 05:02
v3.4.0
64ed128
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

AuthEndpoints

3.4.0 adds map methods you can call on their own. MapIdentityManagementApi, MapCookieAuthEndpoints, MapBearerAuthEndpoints, MapJwtAuthEndpoints, and MapPasskeyEndpoints stay, and each still maps the same routes as 3.3.0. MapAuthEndpoints keeps that default route set. Nothing in the public API was removed or renamed. This release adds no database migration.

The new maps are password (MapPasswordEndpoints), cookie and Identity bearer sessions (MapCookieSessionEndpoints, MapBearerSessionEndpoints), JWT create and session (MapJwtPasswordEndpoints, MapJwtSessionEndpoints), passkey sign-in and credential management (MapPasskeySignInEndpoints, MapPasskeyManagementEndpoints), shared confirm-email (MapConfirmEmailEndpoints), and account management (MapAccountManagementEndpoints). AddPasswordEndpoints, AddCookieSessionEndpoints, AddBearerSessionEndpoints, AddAccountManagementEndpoints, and AddAuthEndpointsIdentity register the services those maps use. AddAccountAbuseRateLimiting and AddConfirmIdentityRateLimiting are public.

When a Map* method runs and its Add* method was not called, AuthEndpoints writes a warning. The category is AuthEndpoints. The message is {AddMethod} was not called before {MapMethod}. The routes are still mapped. MapConfirmEmailEndpoints warns AddAccountAbuseRateLimiting was not called before MapConfirmEmailEndpoints. when that policy marker is missing. AddPasskeyEndpoints also registers the password, cookie-session, and account-management modules, so a host that only calls AddPasskeyEndpoints before MapIdentityManagementApi and MapCookieAuthEndpoints does not get those warnings.

Mapping the same HTTP method and path twice logs {FirstMap} and {SecondMap} both map {METHOD path}. MapIdentityManagementApi with MapCookieAuthEndpoints does not overlap: management uses PasswordLoginMode.None. MapPasswordEndpoints in cookie mode together with MapCookieAuthEndpoints on the same prefix duplicates POST /login. Cookie and bearer session maps need different prefixes. MapJwtPasswordEndpoints and MapJwtSessionEndpoints can share a prefix. MapPasskeyEndpoints must not share a prefix with MapPasskeySignInEndpoints or MapPasskeyManagementEndpoints.

Confirm-email is mapped once per endpoint name. The default name is AuthEndpointsEndpointNames.ConfirmEmail<TUser>(), which is MapIdentityManagementApi-{TUser}-confirmEmail. A later map with that same name leaves the first route in place. Pass a different confirmEmailEndpointName when two groups should each expose GET /confirmEmail.

MapAccountManagementEndpoints maps POST /confirmIdentity/passkeyOptions when AddPasskeyEndpoints was called. MapIdentityManagementApi still maps that route either way, so the 3.3.0 management set stays intact. MapPasskeySignInEndpoints maps confirm-email on the parent group when that name is new. MapPasskeyEndpoints does not map confirm-email.

POST /confirmIdentity still accepts a password, an authenticator code, a recovery code, or a passkey assertion. An emailed code is not a step-up proof in this release.

An email-code host can skip password register and login. See Email-code sign-in with a cookie session.

Upgrading from 3.3.x

  • Existing Add* and Map* calls keep their routes. No host change is required.
  • Hosts coming from 3.3.0 follow the 3.3.1 MagicLink.LinkUri rule: an absolute http or https URI with no #. A rooted path such as /auth/email-link is accepted when MagicLink.BuildLinkUrl is set.
  • A second confirm-email map that reuses the default endpoint name leaves the first route in place. MapConfirmEmailEndpoints returns a no-op builder in that case. Conventions on that builder do not reach the existing route.
  • A missing Add* is a warning in the AuthEndpoints log category. Register the matching Add* so rate limits, ReAuth schemes, and antiforgery are present.
  • A later AddAuthEndpoints or AddAuthEndpointsIdentity call for the same user type applies its options and registers roles. Requesting a different role type than the one already registered throws at startup.
  • A wrong authenticator code during email-code sign-up, when the create loses to an existing two-factor user, clears the consume and keeps the attempt. That matches the existing-user path.

Packages

  • AuthEndpoints 3.4.0
  • AuthEndpoints.External.OAuth 3.0.0-preview.5
  • AuthEndpoints.OAuth.GitHub and AuthEndpoints.OAuth.Google unchanged at 3.0.0-preview.4

Links

Assets 2
Loading