12
113
Fork
You've already forked django-allauth
149

Able to login with passkey, whether passwordless is checked or not when passkey is created #4599

Open
opened 2025年11月06日 01:38:50 +01:00 by marcpfuller · 0 comments

When MFA_PASSKEY_LOGIN_ENABLED is True, users can authenticate with passkeys regardless of the individual credential's passwordless field setting. The passwordless checkbox on the WebAuthn credential creation form appears to have no effect on authentication behavior.

Expected Behavior

When a WebAuthn credential is created with passwordless=False (checkbox unchecked), that specific credential should not be usable for passwordless authentication

Only credentials with passwordless=True should be allowed for passwordless login

The global MFA_PASSKEY_LOGIN_ENABLED setting should enable the feature, but individual credentials should be filtered based on their passwordless field

Actual Behavior

Users can authenticate with any WebAuthn credential using the "Sign in with a passkey" button, regardless of the credential's passwordless setting

The passwordless checkbox setting is stored but not enforced during authentication

Steps to Reproduce

Set MFA_PASSKEY_LOGIN_ENABLED = True in settings
Create a WebAuthn credential with the passwordless checkbox unchecked (passwordless=False)
Navigate to login page
Click "Sign in with a passkey" button
Use the credential that was created with passwordless=False
Result: Authentication succeeds when it should fail
Environment
django-allauth[mfa] version: 65.11.2
Django version: 4.2.16
Python version: 3.10
Additional Context
The authentication flow should check both:

Global setting: MFA_PASSKEY_LOGIN_ENABLED = True
Individual credential setting: credential.passwordless = True
Currently, only the global setting appears to be enforced, making the per-credential passwordless field ineffective.

When MFA_PASSKEY_LOGIN_ENABLED is True, users can authenticate with passkeys regardless of the individual credential's passwordless field setting. The passwordless checkbox on the WebAuthn credential creation form appears to have no effect on authentication behavior. Expected Behavior When a WebAuthn credential is created with passwordless=False (checkbox unchecked), that specific credential should not be usable for passwordless authentication Only credentials with passwordless=True should be allowed for passwordless login The global MFA_PASSKEY_LOGIN_ENABLED setting should enable the feature, but individual credentials should be filtered based on their passwordless field Actual Behavior Users can authenticate with any WebAuthn credential using the "Sign in with a passkey" button, regardless of the credential's passwordless setting The passwordless checkbox setting is stored but not enforced during authentication Steps to Reproduce Set MFA_PASSKEY_LOGIN_ENABLED = True in settings Create a WebAuthn credential with the passwordless checkbox unchecked (passwordless=False) Navigate to login page Click "Sign in with a passkey" button Use the credential that was created with passwordless=False Result: Authentication succeeds when it should fail Environment django-allauth[mfa] version: 65.11.2 Django version: 4.2.16 Python version: 3.10 Additional Context The authentication flow should check both: Global setting: MFA_PASSKEY_LOGIN_ENABLED = True Individual credential setting: credential.passwordless = True Currently, only the global setting appears to be enforced, making the per-credential passwordless field ineffective.
Sign in to join this conversation.
No Branch/Tag specified
main
fix/account-middleware-reauth-exc-vs-api
65.12.x
65.11.x
feat/openid-connect-id-token
fix/phone-vs-social-signup
65.8.x
feat/idp
feat/resend-code-or-change
fix/phone-signup-conflict
feat/phone
fix/headless-email-verification-by-code
fix/a11y
feat/facebook-limited-login
fix/headless-only-connect-reauth
fix/email-added-vs-code-verification
feat/login-required-middleware
0.63.x
refactor-unique-true-field
0.62.x
0.57.x
0.60.x
0.55.x
feat-metamask
65.18.0
65.17.0
65.16.1
65.16.0
65.15.1
65.15.0
65.14.3
65.14.2
65.14.1
65.14.0
65.13.1
65.13.0
65.12.1
65.12.0
65.11.2
65.11.1
65.11.0
65.10.0
65.9.0
65.8.1
65.8.0
65.7.0
65.6.0
65.5.0
65.4.1
65.4.0
65.3.1
65.3.0
65.2.0
65.1.0
65.0.2
65.0.1
65.0.0
64.2.1
64.2.0
64.1.0
64.0.0
0.63.6
0.63.5
0.63.4
0.63.3
0.63.2
0.63.1
0.63.0
0.62.1
0.62.0
0.57.2
0.61.1
0.57.1
0.61.0
0.60.1
0.60.0
0.59.0
0.58.2
0.58.1
0.58.0
0.57.0
0.56.1
0.56.0
0.55.2
0.55.1
0.55.0
0.54.0
0.53.1
0.53.0
0.52.0
0.51.0
0.50.0
0.49.0
0.48.0
0.47.0
0.46.0
0.45.0
0.44.0
0.43.0
0.42.0
0.41.0
0.40.0
0.39.1
0.39.0
0.38.0
0.37.1
0.37.0
0.36.0
0.35.0
0.34.0
0.33.0
0.32.0
0.31.0
0.30.0
0.29.0
0.28.0
0.27.0
0.26.1
0.26.0
0.25.2
0.25.1
0.25.0
0.24.1
0.24.0
0.23.0
0.22.0
0.21.0
0.20.0
0.19.1
0.19.0
0.18.0
0.17.0
0.16.1
0.16.0
0.15.0
0.14.2
0.14.1
0.14.0
0.13.0
0.12.0
0.11.1
0.11.0
0.10.1
0.10.0
0.9.0
0.8.3
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
allauth/django-allauth#4599
Reference in a new issue
allauth/django-allauth
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?