DOMAIN and rp_id should detach in webuthn context

[Bert-Proesmans]

Given configuration values "domain"(config) and "domain_origin"(config).
Domain(config) defines the full URL to access the vaultwarden application.
Domain_origin(config) defines the canonical origin (scheme + domain name + port)

vaultwarden/src/config.rs

Lines 576 to 580 in 57bdab1

	domain: String, true, def, "http://localhost".to_string();
	/// Domain Set |> Indicates if the domain is set by the admin. Otherwise the default will be used.
	domain_set: bool, false, def, false;
	/// Domain origin |> Domain URL origin (in https://example.com:8443/path, https://example.com:8443 is the origin)
	domain_origin: String, false, auto, |c| extract_url_origin(&c.domain);

vaultwarden/src/config.rs

Lines 1302 to 1305 in 57bdab1

	fn extract_url_origin(url: &str) -> String {
	match Url::parse(url) {
	Ok(u) => u.origin().ascii_serialization(),
	Err(e) => {

The webauthn_rs library is initialised with "rp_id"(auth) and "origin"(auth). (RP = relying party aka the browser here)
rp_id(auth) parameter is defined as the "authority" of the authentication environment, used as identification for backend application and security key material.
[rp_]origin(auth) parameter is defined as the location where the relying party makes contact with users/security key.

The rp_id(auth) argument is constructed from the domain name of domain(config). this is basically always a 1-to-1 domain name mapping eg,

domain(config)	rp_id(auth)
mydomain.com	mydomain.com
vault.mydomain.com	vault.mydomain.com

The origin(auth) argument is constructed from domain_origin(config), which is itself constructed from domain(config). This summarises to taking the domain name part of domain(config).

domain(config)	rp_id(auth)	origin(auth)
mydomain.com	mydomain.com	mydomain.com
vault.mydomain.com	vault.mydomain.com	vault.mydomain.com

So rp_id and rp_origin are always set to equal values. With this constraint the system currently works as expected.

vaultwarden/src/api/core/two_factor/webauthn.rs

Lines 32 to 44 in 57bdab1

	static WEBAUTHN: LazyLock<Webauthn> = LazyLock::new(|| {
	let domain = CONFIG.domain();
	let domain_origin = CONFIG.domain_origin();
	let rp_id = Url::parse(&domain).map(|u| u.domain().map(str::to_owned)).ok().flatten().unwrap_or_default();
	let rp_origin = Url::parse(&domain_origin).unwrap();
	let webauthn = WebauthnBuilder::new(&rp_id, &rp_origin)
	.expect("Creating WebauthnBuilder failed")
	.rp_name(&domain)
	.timeout(Duration::from_millis(60000));
	webauthn.build().expect("Building Webauthn failed")
	});

But rp_id should become detached from domain(config) to be semantically correct. (rp_origin remains derived from domain(config).)
This will enable replicated setups in the future. The following scenario's becomes instantly possible;

• limited option to change the vaultwarden URL/domain(config) without the need to reregister keys
• a semi-anycast system of loadbalancers over different vps servers where each has their own dns name

rp_id(auth)	domain(config)	rp_origin(auth)	browser domain	Could work	Works now
my.domain.com	https://my.domain.com/vault	my.domain.com	my.domain.com/vault	✅	✅
^same^	https://other.domain.com	other.domain.com	other.domain.com	❌	❌
domain.com	https://my.domain.com	my.domain.com	my.domain.com	✅	❌
^same^	https://other.domain.com	other.domain.com	other.domain.com	✅	❌
^same^	https://my.domain.com	my.domain.com	other.domain.com	✅	❌

As for how to approach this, my suggestion is to introduces a new configuration parameter ~"webauth_domain" with a default value of domain(config).origin().domain(). Admins can set this to a custom value, and the webauthn_rs library will make sure this value is correct in relation to rp_origin

[BlackDex]

Is only a matching host+tld allowed? Else extracting the host+tld with by creating something like allow all sub domains or something might be an option to.

[Bert-Proesmans]

Is only a matching host+tld allowed? Else extracting the host+tld with [...]

The only requirement that rp_id is held to is that it must be equal to or above in the domain hierarchy from rp_origin, so yes but not all toplevel domains are equal (see domain rules system).

I don't think it's a good idea to default to the TLD + second level domain part (eg vault.mydomain.com => rp_id: mydomain.com), even with domain rules incorporated. This approach doesn't consider best practice in securing domain names for webauthn** (eg vault.passwords.mydomain.com or myvault.eu.passwords.mydomain.com => rp_id: passwords.mydomain.com) which we cannot predict automatically.

** Basically the same underpinning for the existence of the domain rules system, but applied within individual domain names.
In summary, it's best to restrict your secure applications to a subdomain (host.**sub.**mydomain.com) instead of host.mydomain.com. The latter leaves your application no other option than to store session data underneath mydomain.com where all other applications can access the data. Even malicious.deep.within.mydomain.com can access session data underneath mydomain.com, but cannot access data underneath sub.mydomain.com since it doesn't share hierarchy.

[..] allow all sub domains

The option to allow subdomains would need to be set (un)conditionally regardless. This could happen automatically if ~"webauth_domain" != domain(config) without the need for an extra configuration option.

[Bert-Proesmans]

Took a stab at implementing the suggestion;
main...Bert-Proesmans:vaultwarden:rp_id_domain

EDIT; I can test this with multiple real users after the webauthn-rs rework lands in stable. There is too much distance between current stable and current master for me to just throw this into production. x)