feat: allow multiple origins set per RelyingParty

[obroshnij]

As described in the issue #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:

# 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]

Hey @obroshnij 👋 thank you so much for your time and effort!

I like where this is going!

I will try to give a proper test to this in the next week to see how it works in a real app. I'll let you know once I've done it 🙂

Then again, thanks!

[obroshnij]

@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

[obroshnij]

@santiagorodriguez96 I know you guys are pretty busy, but just so that I can also manage my expectations, is there a chance to get this patch merged any time soon?

[santiagorodriguez96]

Hey @obroshnij! Thank you for taking the time and the patience for addressing the comments. Sorry that it took me some time to get back to you again.

I've left a couple more comments in order to keep this moving forward 🙂

Then again thank you!

[obroshnij]

hey @santiagorodriguez96 thanks a lot for another review. I have addressed the points you brought up and I think it should be ready for the next review

[obroshnij]

hi @santiagorodriguez96 thanks for running the CI here. I have fixed the rubocop issues now

[santiagorodriguez96]

Hi @obroshnij! The PR looks good to me!

I'd want to hold off for merging as my plan was to release this as part of v3.3 as we have a lot of features coming in v3.2 too and this one is already a pretty big one 😕

I'll try to release v3.2 and v3.3 in the following days 🙂

[obroshnij]

Hi @obroshnij! The PR looks good to me!

I'd want to hold off for merging as my plan was to release this as part of v3.3 as we have a lot of features coming in v3.2 too and this one is already a pretty big one 😕

I'll try to release v3.2 and v3.3 in the following days 🙂

awesome, I'm looking forward to that 🚀