Current workaround is to fallback to creating multiple RP abstractions per expected client platform (Android, iOS, etc) and select one of them based on User-Agent header (for example). That is of course troublesome and can actually be avoided.
This PR allows a relying party to specify either string for origin or array of strings like in the example:
# config/initializers/webauthn.rb
WebAuthn.configure do |config|
# This value needs to match `window.location.origin` evaluated by
# the User Agent during registration and authentication ceremonies.
# config.origin = "https://auth.example.com/"
config.origin = [
"https://auth.example.com/",
"android:apk-key-hash:blablablablablalblalla"
]
# Relying Party name for display purposes
config.rp_name = "Example Inc."
config.rp_id = "example.com"
end
The only drawback of this approach is that in case an array is used for config.origin, - it's impossssible to "guess" relying party by origin (which maybe we should not even do?) thus having array there and no explicitly set config.rp_id would result in RpIdVerificationError which imo should be expected.
Hope this PR makes sense. Please let me know should there be any change requests/questions
@santiagorodriguez96 thanks a lot for a review and feedback. I have address the points that you brought earlier. Please let me know if there is still anything I should improve
As described in the issue https://github.com/cedarcode/webauthn-ruby/issues/428 when building a Relying Party that is supposed to be used by iOS and Android native clients, we need to be able to specify multiple allowed origins per RP (https://developer.android.com/identity/sign-in/credential-manager#verify-origin) This is yet not supported by this library though is also part of standard specification https://w3c.github.io/webauthn/#sctn-validating-origin
Current workaround is to fallback to creating multiple RP abstractions per expected client platform (Android, iOS, etc) and select one of them based on
User-Agent
header (for example). That is of course troublesome and can actually be avoided.This PR allows a relying party to specify either string for origin or array of strings like in the example:
The only drawback of this approach is that in case an array is used for
config.origin
, - it's impossssible to "guess" relying party by origin (which maybe we should not even do?) thus having array there and no explicitly setconfig.rp_id
would result inRpIdVerificationError
which imo should be expected.Hope this PR makes sense. Please let me know should there be any change requests/questions