Expected Behavior
WebAuthnAuthenticationFilter should expose an AuthenticationConverter setter
so that applications can extract additional request context (e.g. custom JSON fields,
query parameters, or headers) and make them available during the authentication flow.
A default implementation preserves existing behavior. Custom implementations could
enrich the resulting Authentication token or store extra context as request
attributes, making them accessible to the AuthenticationSuccessHandler.
This is consistent with patterns already established in other Spring Security filters
(e.g. UsernamePasswordAuthenticationFilter, BearerTokenAuthenticationFilter).
Current Behavior
attemptAuthentication hard-codes the deserialization target to
PublicKeyCredential<AuthenticatorAssertionResponse>:
ResolvableType resolvableType = ResolvableType.forClassWithGenerics(
PublicKeyCredential.class, AuthenticatorAssertionResponse.class);
publicKeyCredential = this.converter.read(resolvableType, httpRequest, null);Any extra fields sent in the request body are silently dropped by Jackson.
The resulting WebAuthnAuthenticationRequestToken only carries a
RelyingPartyAuthenticationRequest (credential + options) with no room
for application-level context.
There is no hook to intercept or extend what is read from the request before
the token is built and passed to the AuthenticationManager.
Context
In a stateless passkey flow (JWT-based, no server-side session), the frontend
needs to pass additional data alongside POST /login/webauthn — for example,
a device identifier or login-context token — so that the AuthenticationSuccessHandler
can include it in the issued JWT.
The only working workaround today is URL query parameters:
POST /login/webauthn?deviceId=abc123
These are readable from HttpServletRequest in the success handler, but query
parameters appear in server access logs, which is undesirable for identifiers
that should be treated as semi-sensitive.
A custom AuthenticationConverter setter on WebAuthnAuthenticationFilter would
allow structured data to be read from the body or headers and forwarded cleanly
through the authentication flow without workarounds.
Expected Behavior
WebAuthnAuthenticationFiltershould expose anAuthenticationConvertersetterso that applications can extract additional request context (e.g. custom JSON fields,
query parameters, or headers) and make them available during the authentication flow.
A default implementation preserves existing behavior. Custom implementations could
enrich the resulting
Authenticationtoken or store extra context as requestattributes, making them accessible to the
AuthenticationSuccessHandler.This is consistent with patterns already established in other Spring Security filters
(e.g.
UsernamePasswordAuthenticationFilter,BearerTokenAuthenticationFilter).Current Behavior
attemptAuthenticationhard-codes the deserialization target toPublicKeyCredential<AuthenticatorAssertionResponse>:Any extra fields sent in the request body are silently dropped by Jackson.
The resulting
WebAuthnAuthenticationRequestTokenonly carries aRelyingPartyAuthenticationRequest(credential + options) with no roomfor application-level context.
There is no hook to intercept or extend what is read from the request before
the token is built and passed to the
AuthenticationManager.Context
In a stateless passkey flow (JWT-based, no server-side session), the frontend
needs to pass additional data alongside
POST /login/webauthn— for example,a device identifier or login-context token — so that the
AuthenticationSuccessHandlercan include it in the issued JWT.
The only working workaround today is URL query parameters:
These are readable from
HttpServletRequestin the success handler, but queryparameters appear in server access logs, which is undesirable for identifiers
that should be treated as semi-sensitive.
A custom
AuthenticationConvertersetter onWebAuthnAuthenticationFilterwouldallow structured data to be read from the body or headers and forwarded cleanly
through the authentication flow without workarounds.