Closed Charl00 closed 9 months ago
Hello @Charl00, unfortunately with issues like this it's highly likely to be a problem between the OS, the browser, and the mobile device that's performing the hybrid registration ceremony. If you see the error after scanning the QR code but while completing the prompt on your mobile device then something is probably failing between the Android device and your MacBook.
For what it's worth I also encounter this issue with a Pixel 6 running Android 14 when scanning the hybrid QR code from Chrome 122 on macOS 14.3 showing the SimpleWebAuthn example site. I have an OS update pending so that could be partially responsible, but honestly there's nothing at the SimpleWebAuthn level to really "fix" here...
@Charl00 @MasterKale I have the same problem. My cross device integration is dead in the water after having worked for so many months perfectly.
Mobile OS: Android 13 PC: OpenSuse Tumbleweed and Chrome.
The same problem happens when testing against webauthn.io. I have verified using Google password manager that the passkey is in fact stored in there during a registration. SimpleWebAuthn seems to give up when doing a registration or authentication as it doesn't wait for the biometric/screen lock to be unlocked in the phone, IIRC this is a new step and Google has changed the passkey flow. For example, a few months ago Chrome didn't show me the resident credentials associated with a website but now it does and I can choose from Chrome on PC itself which user/ID I want, prior to this, the choosing of user/ID happened on the phone itself.
As for my integration, just do a normal login on the demo and configure passkey: https://demo.mymailcheap.com/web/panel/myaccount.html
@Charl00 @MasterKale I have the same problem. My cross device integration is dead in the water after having worked for so many months perfectly.
Mobile OS: Android 13 PC: OpenSuse Tumbleweed and Chrome.
The same problem happens when testing against webauthn.io. I have verified using Google password manager that the passkey is in fact stored in there during a registration. SimpleWebAuthn seems to give up when doing a registration or authentication as it doesn't wait for the biometric/screen lock to be unlocked in the phone, IIRC this is a new step and Google has changed the passkey flow. For example, a few months ago Chrome didn't show me the resident credentials associated with a website but now it does and I can choose from Chrome on PC itself which user/ID I want, prior to this, the choosing of user/ID happened on the phone itself.
As for my integration, just do a normal login on the demo and configure passkey: https://demo.mymailcheap.com/web/panel/myaccount.html
@pavinjosdev is it possible that the timeout isn't being respected or is explicitly set too low? https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create#timeout
@wparad is it possible that the timeout isn't being respected or is explicitly set too low? https://developer.mozilla.org/en-US/docs/Web/API/CredentialsContainer/create#timeout
Testing against webauthn.io appears to indicate timeout isn't the problem. Perhaps something in Android is broken, I can't rule it out. For example, NFC has been broken forever on my phone (could never get it to work with Yubikey NFC). Now that they've moved the passkey request handling from Chrome to Google Play (or some other Android sub system) it could be the phone that's faulty.
I personally use brave for that, just to rule out any chrome related issues. And besides some, ahem, developer driven issues, it's been totally working on every site/browser. What's weird is we are using this library for part of our server side, and using the raw browser side apis on the client side. I'd almost be curious, if you end up with a problem when using our site. If you want to test it out, we could at least get logs on the problem (or even better validation on where the issue is). Happy to help, just let me know and I can drop the link in here.
@wparad If you want to test it out, we could at least get logs on the problem (or even better validation on where the issue is). Happy to help, just let me know and I can drop the link in here.
Yes, I'd like that 🙂
Going to here in Chrome on the non-mobile computer you're trying to log in from may help diagnose things further:
chrome://device-log/?refresh=5
You can tick just the FIDO box and see how Chrome tries to perform hybrid reg/auth.
@MasterKale Thanks, that was helpful:
FIDODebug[21:59:47] Advertisements stopped
FIDODebug[21:59:47] Stopping 0 caBLE advertisements
FIDOError[21:59:47] Failing make credential request due to status 0x27 (kCtap2ErrOperationDenied) from tunnel-94A01F6B174A5393
FIDODebug[21:59:47] <- (cancel)
FIDODebug[21:59:47] -> (CTAP2 error code 0x27 (kCtap2ErrOperationDenied))
FIDODebug[21:59:44] <- 0x1 (kAuthenticatorMakeCredential) {1: h'3896D8BDFE7BFC1B4C68E020DF84A74A0F2AA0B9A05DC9A585B9FE586279A156', 2: {"id": "webauthn.io", "name": "webauthn.io"}, 3: {"id": h'6447567A64475679', "name": "tester", "displayName": "tester"}, 4: [{"alg": -7, "type": "public-key"}, {"alg": -257, "type": "public-key"}], 5: [{"id": h'FEB6BD23B5F251BE5D3A1D78F6B69606', "type": "public-key"}], 7: {"rk": true, "uv": true}}
FIDODebug[21:59:44] The device supports the CTAP2 protocol.
FIDODebug[21:59:44] -> {1: ["FIDO_2_0", "FIDO_2_1"], 2: ["prf"], 3: h'00000000000000000000000000000000', 4: {"rk": true, "up": true, "uv": true, "plat": false}, 9: ["internal", "hybrid"]}
FIDODebug[21:59:44] tunnel-94A01F6B174A5393: established v2.1
As I understand it, the browser sends credential creation request and Android replies with an error code, though everything looks good from the Android user's POV. Could you confirm this is an Android bug?
@wparad If you want to test it out, we could at least get logs on the problem (or even better validation on where the issue is). Happy to help, just let me know and I can drop the link in here.
Yes, I'd like that 🙂
:+1: Accounts are available at login and you can try to create a key using the user drop down menu and selecting Security Keys.
If there are any problems, hopefully we'll find out, otherwise it will help us narrow down where the bug could be:
@wparad Same error as above when testing with webauthn.io.
FIDODebug[22:26:41] Advertisements stopped
FIDODebug[22:26:41] Stopping 0 caBLE advertisements
FIDOError[22:26:41] Failing make credential request due to status 0x27 (kCtap2ErrOperationDenied) from tunnel-375B0291F8DEFFB1
FIDODebug[22:26:41] -> (CTAP2 error code 0x27 (kCtap2ErrOperationDenied))
@wparad @MasterKale The issue was with Chrome it would seem. Everything is working well in Chrome v114 on desktop and 124 on mobile.
Describe the issue
When running the SimpleWebauthn example project I noticed devices which do not have something like Samsung Pass, for example, are not able to save passkeys and return a NotAllowedError. See screenshot below.
Reproduction Steps
All below steps were conducted on the example project supplied with SimpleWebAuthn
See screenshot
Expected behaviour
When a passkey is created using a Android phone, the user should be able to create a passkey and subsequently authenticate with it as well.
Code Samples + WebAuthn Options and Responses
The defaults set within the example project.
Dependencies
SimpleWebAuthn Libraries
Additional context
When something like Samsung pass is involved it seems fine. Feels like potentially something could be whack on the Google side of the equation.