MFA should not merge `Authentication` instances with different `Principal.getName()`

[zyro23]

Describe the bug
when using the new MFA support with factors belonging to different principals, you end up with an Authentication that has the principal of the last factor and all authorities of the different principals.

To Reproduce

• require multiple factors
• authenticate using one factor
• authenticate using a second factor as a different user

Expected behavior

• i guess either the authentication attempt for the second factor should fail
• or the authentication from the first factor should be discarded

Sample

sample app (password and ott) will be referenced asap:

• run
• login as user / password
• request an ott for username admin (i.e. remove the username input readonly attribute)
• use the generated ott (console out / info log)
• see log for the resulting Authentication

2025-10-28T05:52:12.326+01:00 DEBUG 23184 --- [demo] [nio-8080-exec-6] s.w.a.o.OneTimeTokenAuthenticationFilter : Set SecurityContextHolder to OneTimeTokenAuthentication [Principal=org.springframework.security.core.userdetails.User [Username=admin, Password=[PROTECTED], Enabled=true, AccountNonExpired=true, CredentialsNonExpired=true, AccountNonLocked=true, Granted Authorities=[ROLE_ADMIN]], Credentials=[PROTECTED], Authenticated=true, Details=null, Granted Authorities=[ROLE_ADMIN, FactorGrantedAuthority [authority=FACTOR_OTT, issuedAt=2025-10-28T04:52:12.323991700Z], ROLE_USER, FactorGrantedAuthority [authority=FACTOR_PASSWORD, issuedAt=2025-10-28T04:49:26.419396Z]]]

note that the behavior is the same, if, for example, the first factor is a passkey and the second is username/password.

[rwinch]

Thank you for your feedback @zyro23

MFA is designed around the GrantedAuthority and so it is expected that the GrantedAuthority instances of the different Authentication instances would be merged.

i guess either the authentication attempt for the second factor should fail

Why would you expect this? The feature is to support Multi Factor Authentication (MFA), so I'd expect that the user can authenticate using a second factor (otherwise MFA is not supported). Without the second factor, the application cannot enforce the requirement that two factors are required.

or the authentication from the first factor should be discarded

Why would you expect this? If the results from the first Authentication (factor) are discarded, then you no longer have MFA. Again, without information from the first Authentication, the application cannot enforce the requirement that two factors are required.

The description of this just states that the factors are not associated to the same principal without elaborating on what problems this is causing you. Can you explain why this is causing problems?

[zyro23]

thanks as well @rwinch for the feedback.

to summarize my concerns: the sample app defines two users:

• username user with role USER
• username admin with role ADMIN

i would not expect - using any combination of factors - that an authentication results in both authorities ROLE_USER and ROLE_ADMIN being granted at the same time. especially not with one factor authenticated with username user and another factor authenticated with username admin.

i hope that makes sense and clarifies why this is causing problems - or at least for me is unexpected behavior.

[rwinch]

Thanks for the feedback. We've decided that we are planning on doing the following:

• The default MFA will ensure that the principals are the same
• Make MFA an opt in. This is because no matter how we decide to do MFA there are going to be some sort of compromises on how the Authentication instances are merged. By requiring an opt in, users are agreeing to those semantics

Do you think that this will alleviate your concerns?

[zyro23]

that sounds good! thanks a lot for taking this into consideration. much appreciated.

[rwinch]

I should add that we are still deciding on exactly what it means for the principals to be the same. At the moment I am thinking it might just be Authentication.getName() is the same (this is how Principal API determines if two Principal instances are the same).

[zyro23]

agreed that that is a sensible default implementation. maybe it would make sense to put that equality check into some kind of configurable Predicate<Authentication> / BiPredicate<Authentication, Authentication> or similar, should future need for customization arise?