Multiple expectedOrigin and expectedRPID

[Mikescops]

Hello,

Thanks for your great work.

I have a use case that seems not working with the current implementation of the lib.
When using SimpleWebAuthn on a browser extension I have different expectedOrigin and expectedRPID for Firefox / Chrome / ...
Maybe I'm wrong but the only way I see to have the lib working with this use case is to change both expectedOrigin and expectedRPID from string to tables so that I can check if the origin and rpId in the attestation/assertion are in the list.

Is my interpretation correct and is it worth to support this use case in the lib?

[MasterKale]

It's hard to comment on this without knowing more about your use case but can't that lookup information and logic not reside in the extension, prior to calling verifyAttestationResponse or verifyAssertionResponse? Typically a server implementing this library is only going to have a single expected RP ID and origin. The fact that you're using this library in a browser extension immediately stumps me because it's not a use case that was ever on my radar...

[Mikescops]

From the test we made the origin is different between browsers (and dev/prod environement) as the extension register with a built-in origin, for instance on Firefox it is moz-extension://dbac9369-xxxx-xxxx-xxxx.
So in our case the browser extension ask the server on api.domain.com for the challenge, do its webauthn.create/get and send it back to the server for validation.
We could somehow detect that it's a chrome or firefox browser extension that is calling us and then choose the right expectedOrigin/RPID but that would be way easier with the proposal I made in my previous message.
Let me know what you think :)

EDIT: plus I'm really looking to have the server part interoperable with Android/iOS native apps.

[MasterKale]

Oh, are you using WebAuthn to protect access to some aspect of your browser extension? What a fascinating use case! I see now, with UUID-like origins like that, how it would be difficult to ensure a consistent RP ID across environments.

So then, to clarify, the request is to change expectedOrigin and expectedRPID to accept string | string[] instead of just string so that multiple possible values for either can be passed into the verify methods?

[Mikescops]

Yes, exactly, two use cases: 2FA and access validation (I can give you concrete examples of this in private as I don't want to leak too much information publicly).

So then, to clarify, the request is to change expectedOrigin and expectedRPID to accept string | string[] instead of just string so that multiple possible values for either can be passed into the verify methods?

Correct, then it would be something like if (!expectedOrigin.includes(data.origin)) return new Error('wrong origin');.
If you agree with this, I can work on a pull request.

[MasterKale]

@Mikescops Take a look at PR #91 and let me know if anything looks off, otherwise I'll merge it in later today and cut a release.

[Mikescops]

@MasterKale wow that's fast, thanks! 👍