goauthentik / goauthentik/authentik
webauthn device not bound to brand
- Dominant language
- Python
- Stars
- 25.6k
- Forks
- 2k
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 659
Description
### Describe the bug
I have a single authentik instance with two brands (a.example.com and b.example.net)
The authentication flow for both has a `default-authentication-mfa-validation` stage.
I registered a security key on brand A, the key on the device has an RP ID of a.example.com
When I try to login to brand B, b.example.net, and try to use webauthn authentication, the RP ID does no match.
When trying to register the device again on b.example.net, I get "Credential ID already exists".
### How to reproduce
1. Setup two brands with an authentication flow with `default-authentication-mfa-validation`
2. Login to brand A and register a webauthn device.
3. Try to login to brand B
4. When asked to sign in with passkey, try to use the webauthn device
-> can't sign in because security key doesn't recognize relying party (RP)
5. Login to brand B after enrolling another mfa device (e.g. email or totp) via brand A
6. Try to enroll the same device on brand B
-> Credential ID already exsists
### Expected behavior
When using brand B, the device enrolled on brand A should not considered for login (i.e. `devices_for_user` and `ak_user_has_authenticator` and the authenticator validation stage should filter on device RP ID)
I should be able to enroll a webauthn device that was already enrolled with different RP ID.
### Screenshots
Using the security key on brand B:
Trying to register the security key on brand B:
### Additional context
- Firefox 152.0.4
- Windows 11
- Thetis Security Key (Excelsecu eSecu FIDO2 NFC Security Key, a3975549-b191-fd67-b8fb-017e2917fdb3)
### Deployment Method
Docker
### Version
2026.5.3
### Relevant log output
```shell
```
Contributor guide
Research direction
Start by tracing the named devices_for_user and ak_user_has_authenticator paths, then inspect how the authenticator validation stage handles brands and WebAuthn RP IDs. Confirm that a credential enrolled under one brand is excluded from another and that the same security key can be enrolled with a different RP ID.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authentication, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100