Replies: 1 comment 5 replies
-
|
Hi, The authenticator is returning a
You are sending a rather large request of 1247 bytes
which has grown this large due to the fact that there's 21 allowed credentials in this request. My guess is that the authenticator's max message size is less than 1247 bytes (look for For this many allowed credentials, you will probably need to chunk them into multiple assertions. One way of minimizing user interaction could be to make use of the pre-flight concept to figure out which credential ID:s that the authenticator knows of, before performing the actual assertion ceremony. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks a lot, Ludvig. It's really helpful. In the pre-flight concept, setting "up" to false can verify both confidentialId and Pin code. Both of them are useful for me. However, I noticed that there is no "up" set to false for fido_cred_t. Do you have any ideas on how to verify whether the PIN code is valid or not before the actual fido_dev_make_cred? |
Beta Was this translation helpful? Give feedback.
-
|
One more thing, if I set 'up' to false in an assertion with a U2F device, it returns "FIDO_ERR_USER_PRESENCE_REQUIRED." It seems that it's also not applicable to these devices. Is that correct? Thanks for your help. |
Beta Was this translation helpful? Give feedback.
-
|
Happy to help!
The CTAP specification mandates UP during credential creation. This is enforced by the authenticator. Consequently, there's no toggle for it in libfido2.
You could possibly send an assertion with dummy values first instead (or use pre-flight assertions to determine whether the authenticator is already registered). Otherwise, why not just try the PIN with the actual
This is the expected return value for a U2F authenticator that knows of a credential in the allow list. To accommodate pre-flights for both U2F/CTAP2 authenticators, you would do something along the lines of: /* Error handling and assertion setup omitted for brevity. */
fido_assert_set_up(assert, FIDO_OPT_FALSE);
int r = fido_dev_get_assert(dev, assert, pin); /* pre-flight */
if ((fido_dev_is_fido2(dev) && r == FIDO_OK) ||
(!fido_dev_is_fido2(dev) && r == FIDO_ERR_USER_PRESENCE_REQUIRED)) {
/* OK: Authenticator knows of a credential ID in the allow list. */
} |
Beta Was this translation helpful? Give feedback.
-
|
Thank you very much, Ludvig. Both of the solutions provided above are excellent. Currently, most websites are working fine. However, I encountered a FIDO_ERR_NO_CREDENTIALS error when using fido_dev_get_assert to log in to the Okta website. In this operation, I set fido_assert_set_up(assert, FIDO_OPT_FALSE) for pre-flight to check if the credential is valid or not. Unfortunately, it returns FIDO_ERR_NO_CREDENTIALS. Upon extensive searching within the project, it appears that only cases where rpId and allow_list are not correct will result in No_Credential. However, I believe I have provided the correct rpId and allow_list values, as most websites allow successful login. Could you please provide some suggestions or assistance? Thanks. fido_assert_set_rp("https://console.okta.com") |
Beta Was this translation helpful? Give feedback.
-
|
Since you provide some form of user verification in your request, the only case where Looking at your request, your RP ID contains the scheme ( |
Beta Was this translation helpful? Give feedback.
-
Hello team,
I wrote a program which integrated libfido2. For most of cases， most of the devices and most of the website, fido_dev_get_assert works well. However, to login some website, such as "office365", fido_dev_get_assert returns fido_err_rx.
Could you help with the error? Thanks a lot.
Beta Was this translation helpful? Give feedback.
All reactions