New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Credential Manager: ClientDataJSON origin mismatch with webauthn library (Mismatch between FIDO2 and w3c webauthn) #49
Comments
Update: Manually overriding the "origin" field in clientDataJson allows registration to work, however sign-in fails. I think this is due to the signature FE/BE not matching because of the hacky solution we do changing clientDataJson |
Update:
|
Hey thanks for sharing this, we are looking into this and share an update soon. |
I can also confirm I'm having the exact same problem. |
We do faced that problem as well when integrating Passkey functionality to the app |
Hi all, For the information on origin field on different platforms : Upon registration response, for android, you should check the origin against the facetID based on FIDO spec. it usually follow the format of "android:apk-key-hash:<sha1_hash-of-apk-signing-cert>" . Check this link : https://fidoalliance.org/specs/common-specs/fido-appid-and-facets-v2.1-ps-20220523.pdf the sha1_hash can be calculated following keytool -exportcert -alias androiddebugkey -keystore Let us know if this helps! We shall share the update on InvalidAuthenticationResponse soon! |
We have the same problem with androidx.credentials:credentials:1.2.0 . Is there any workaround? |
Hi all we are having the same issue documented here since July. Passkeys on android webview are not working as per the standard implementation. There is a guide (https://developer.android.com/training/sign-in/passkeys) that describes how to use the credential manager and links to this repository with code that is incomplete. There is a workaround documented here: https://passkeys-auth.com/docs/implementation/flutter/android/ Google is pushing passkeys for some time now.. and yet they are not able to address a simple issue for months! Can anyone assist with code that solves this issue? Thank you |
Hi, for information on origin field : To understand origin on Android, please go through this information : https://developer.android.com/training/sign-in/passkeys#verify-origin And for apps setting up the origin field : We dont recomment the normal client apps to set origin field on their own. Could you please let us know what exact issue you are facing after reading these and we should have fixed the invalid auth. response error? Please let us know. |
Hi, Closing this as no activity, please let me know if there's any other issue. |
Right now android matches the FIDO2 Spec and always sets the FacetID to the android:apk-key-hash
https://fidoalliance.org/specs/uaf-v1.0-id-20141122/fido-appid-and-facets-v1.0-id-20141122.html
This becomes a problem because the w3c webauthn doesn't allow non http:// facet IDs
w3c/webauthn#1297
The python webauthn library will also throw an exception if the decoded "origin" value from clientDataJSON doesn't match the expected_origin.
https://github.com/duo-labs/py_webauthn/blob/d8e78f000b08dcc15d194a904d1c2dd381f87a9c/webauthn/registration/verify_registration_response.py#L124
iOS has mitigated this issue in their webauthn library by forcing you to set the relying party to override the iOS app bundle ID normally used as their Facet ID according to FIDO2 Specs:
https://developer.apple.com/documentation/authenticationservices/asauthorizationplatformpublickeycredentialprovider
I believe this was supposed to be done on android with the origin field in CreatePublicKeyCredentialRequest, however its value doesn't affect the output and looking through source code the field appears to be unused
https://developer.android.com/reference/androidx/credentials/CreatePublicKeyCredentialRequest
Please get this fixed before credential manager is stable, for now it will force developers to do hacky solutions of parsing to Json Objects, decoding, changing, re-encoding, and converting back to a string for the registrationResponseJson.
The text was updated successfully, but these errors were encountered: