search

cedarcode / webauthn-ruby

WebAuthn ruby server library ― Make your Ruby/Rails web server become a conformant WebAuthn Relying Party
https://rubygems.org/gems/webauthn
MIT License
644 stars 51 forks source link

RelyingParty#id should default to the domain of #origin #427

Open asavageiv opened 3 months ago

asavageiv commented 3 months ago

Per the spec the RP ID "must be equal to the origin's effective domain, or a registrable domain suffix of the origin's effective domain." and "By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain."

I was surprised that setting the origin did not automatically set the ID if it was unset. This led to failures when my Android client didn't receive an ID.

Can we set the ID by default per the spec?

santiagorodriguez96 commented 3 months ago

Hi @asavageiv!

Thank you the report!

Currently, if the user has not set an rp_id, we we'll derive it from the specified origin when verifying the authenticator response.

I find it surprising that this was an issue for you when using an Android Client – I'm curious, what issue were you experiencing exactly?

We might have to re-think about the approach that we are using here!

Then again, thanks!

asavageiv commented 3 months ago

Android expects the rpId to exist in the challenge.

santiagorodriguez96 commented 3 months ago

Sorry, I did not mention that the rp_id will in fact be sent in the PublicKeyCredential::CreationOptions (see this) and PublicKeyCredential::RequestOptions (see this) if it was set for the relying party, so you should be good if you configure your relying party with your app's rp_id.

Now, about the rp_id defaulting to the domain of origin: by looking at the spec, sending the RPID in the creation and request options is optional – if it's not sent it will already be populated with the domain of your app's origin by the client. I think the behavior of webauthn-ruby it's pretty close to what's described in the spec - it doesn't send the rp_id unless the user of the gem instantiates its relying party with a value for it – so I don't think we should do anything in this case.