英文:
Webauthn - allowCredentials and credential selection
问题
I am implementing Webauthn where a browser-based client is communicating to a Java back-end using Webauthn4J. In the back-end, I have an association between a registered user and credentials linked to that user. For the authentication flow, I am populating the allowCredentials array with the credentials linked to the user which are active.
我正在实现Webauthn,其中基于浏览器的客户端通过Webauthn4J与Java后端通信。在后端,我将注册用户与与该用户关联的凭据进行了关联。在身份验证流程中,我正在使用与用户关联的处于活动状态的凭据填充allowCredentials数组。
For the purposes of explaining the problem, assume user1 has 3 credentials linked, c1, c2 and c3. What I am seeing on Chrome (v113.0.5672.126, macOS Ventura 13.3.1) is that a single credential is picked from the list of allowCredentials and the user is prompted to authenticate that credential. The way the credential is selected doesn't seem deterministic, it is not the newest or the oldest and is unrelated (from what I've understood) to the order of the credentials listed in the allowCredentials array. If I delete that credential from Chrome's passkeys, then a different credential is selected from the list, but again, only a single credential is presented for authentication.
为了解释这个问题,假设用户1有3个关联的凭据,c1、c2和c3。我在Chrome (v113.0.5672.126, macOS Ventura 13.3.1)上看到的情况是,从allowCredentials列表中选取一个凭据,并提示用户对该凭据进行身份验证。凭据的选择方式似乎并不确定,它既不是最新的也不是最旧的,与在allowCredentials数组中列出的凭据的顺序无关(根据我理解的情况)。如果我从Chrome的通行证中删除了该凭据,那么将从列表中选择另一个凭据,但同样,只会呈现一个凭据用于身份验证。
If I remove the list of allowCredentials, the user is prompted with all 3 credentials for authentication as all 3 credentials are scoped to the domain. I would expect similar behaviour when using allowCredentials with all 3 credentials included.
如果我删除allowCredentials列表,用户将被提示使用所有3个凭据进行身份验证,因为这3个凭据都是针对该域的。我会期望在包括所有3个凭据的情况下使用allowCredentials时会有类似的行为。
The specification states: "The list is ordered in descending order of preference: the first item in the list is the most preferred credential, and the last is the least preferred."
规范中指出:“列表按优先级降序排列:列表中的第一项是最优先的凭据,最后一项是最不喜欢的凭据”。
This is not what I am seeing in practice. Neither the order is respected, nor are all credentials included in the prompt.
实际上我看到的情况与此不符。既不尊重顺序,也不包括在提示中的所有凭据。
Am I misunderstanding how allowCredentials are supposed to work or is this a quirk of the Chrome implementation of Webauthn?
我是不是对allowCredentials的工作原理有误解,或者这是Chrome实现Webauthn的一个特殊情况?
英文:
I am implementing Webauthn where a browser-based client is communicating to a Java back-end using Webauthn4J. In the back-end, I have an association between a registered user and credentials linked to that user. For the authentication flow, I am populating the allowCredentials array with the credentials linked to the user which are active.
For the purposes of explaining the problem, assume user1 has 3 credentials linked, c1, c2 and c3. What I am seeing on Chrome (v113.0.5672.126, macOS Ventura 13.3.1) is that a single credential is picked from the list of allowCredentials and the user is prompted to authenticate that credential. The way the credential is selected doesn't seem deterministic, it is not the newest or the oldest and is unrelated (from what I've understood) to the order of the credentials listed in the allowCredentials array. If I delete that credential from Chrome's passkeys, then a different credential is selected from the list, but again, only a single credential is presented for authentication.
If I remove the list of allowCredentials, the user is prompted with all 3 credentials for authentication as all 3 credentials are scoped to the domain. I would expect similar behaviour when using allowCredentials with all 3 credentials included.
I've verified this behaviour using Webauthn debugger so it doesn't seem to be an implementation problem on my side.
The specification states:
"The list is ordered in descending order of preference: the first item in the list is the most preferred credential, and the last is the least preferred."
This is not what I am seeing in practice. Neither the order is respected, nor are all credentials included in the prompt.
Am I misunderstanding how allowCredentials are supposed to work or is this a quirk of the Chrome implementation of Webauthn?
答案1
得分: 0
问题可能与您在同一设备上为同一用户的同一应用/网站尝试生成的凭据数量有关。尽管用户应该允许拥有多个用于访问帐户的密码,但他们在同一设备上理想情况下只应该有一个应用程序密码(我在这里使用设备这个术语,它可以是类似Google/Apple这样的认证器或提供程序)。
- 鼓励:用户A可以在设备A和设备B上拥有他们的App 1密码。
- 鼓励:设备A可以为用户A和用户B拥有App 1密码。
- 不鼓励:设备A对App 1拥有多个用户A密码。
您应该利用excludeCredentials
列表来阻止客户端应用程序发生这种情况。如果用户尝试在已经有密码的设备上创建新密码,应该抛出错误/警告。
关于第二个问题,涉及到allowCredentials
列表不允许您在填充时选择您的密码。我对这个理解有些模糊,但据我理解,当credentialID
在allowCredentials
列表中填充时,客户端(在这种情况下是Chrome)将尝试查找与credentialID
匹配的特定凭据(无论它是Chrome的密码还是来自外部认证器,比如安全密钥)。如果找到与credentialID
匹配的凭据,Chrome将立即提示您选择它。总的来说,这不是问题,因为您的应用只是在寻找与标准匹配的密码,不一定要选择哪一个。
当您不提供allowCredentials
列表时,Chrome不知道您要寻找哪个特定的凭据(密码)。在这种情况下,浏览器将提示您选择要使用的特定凭据(密码),因为从未向浏览器提示过。
希望这有所帮助。
英文:
The issue might be related to the number of credentials that you're attempting to generate on the same device for the same user for the same app/website. While a user should be allowed to have multiple passkeys to access an account, they ideally should only have one passkey per app on a device (I'm using the term device which could be an authenticator or provider like Google/Apple).
- Encouraged: User A can have their App 1 passkeys on Device A, and Device B
- Encouraged: Device A can have App 1 passkeys for User A and User B
- Discouraged: Device A has multiple User A passkeys for App 1
You should leverage the excludeCredentials
list to prevent this scenario from your client application. An error/alert should be thrown for a user attempting to create a new passkey on a device where they already have one.
On to the second issue on the use of the allowCredentials
list not allowing you to select your passkey when populated. My understanding of this is fuzzy, but as I understand it; when a credentialID
is populated in the allowCredentials
list, the client (in this case Chrome) will attempt to find that specific credential (whether it's part of Chrome's passkeys or from an external authenticator like a security key). If a credential matching the credentialID
is found, Chrome will immediately just prompt for it. Overall this isn't an issue because your app is just looking for any passkey that matches the criteria, it doesn't necessarily matter which you're selecting.
When you don't provide an allowCredentials
list, Chrome doesn't know which specific credential that you're looking for. In this case the browser will prompt you to select the specific credential (passkey) that you want to use, because one was never hinted to the browser.
Hope this helps.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论