server: base64 decoding padded data

[james-d-elliott]

Does @simplewebauthn/server handle edge cases where the frontend sends data as JSON and includes padding when encoding the binary data as base64 or does it reject the padding as invalid? If the former, did you do this intentionally and would you mind explaining? I'm mostly curious as I am presented with a decision regardless.

Also sorry, just realized you explicitly said discussion!

Semi-Related but is more specific regarding the userHandle: #314

[MasterKale]

There isn't anything between @simplewebauthn/browser and @simplewebauthn/server that uses base64 specifically because the spec calls out base64url as a dependency. I do make an accommodation for padding in base64url values, though, in isoBase64URL.isBase64url():

https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/server/src/helpers/iso/isoBase64URL.ts#L63

And to reiterate a point I made in #330, regarding userHandle: within the SimpleWebAuthn project the user.id and userHandle values are only ever encoded/decoded as UTF-8:

• https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/methods/startRegistration.ts#L35
• https://github.com/MasterKale/SimpleWebAuthn/blob/master/packages/browser/src/methods/startAuthentication.ts#L94

Referring back to my explanation for this in #314, this was because during dogfooding I found it very annoying to always have to decode the base64url-encoded userHandle during auth to understand the user's actual user ID. In my mind it made things simpler to keep user.id as a UTF-8 string during registration so that userHandle would end up a human-readable value during auth.

If a developer chooses to set a base64-encoded value as user.id, they'll get back that base64-encoded value as userHandle during auth. SimpleWebAuthn won't transform that value, nor does it have any bearing on how the library will validate the WebAuthn authentication response.

[james-d-elliott]

Forgot to mention that I really appreciate the response. I got really busy with a release cycle and work on the day that I read it. Apologies for not thanking you sooner.

It makes sense the method you took. The user.id doesn't effectively matter to anyone other than the RP in my eyes. As long as the value is in an expected format in output/input from/to the RP then it should work as expected. Seems like in fixing one issue in the go webauthn library I introduced another, but it's easily fixed.

I must say I'm impressed with this library and intend to be using it and guiding implementers towards it. In particular the fact it's written with typescript, and that the library is split nicely into the RP and client side portions. I couldn't find a good typescript webauthn browser library when I first implemented it with authelia and ended up doing most of it myself. This library did exist at the time but not sure I managed to find it. Upside to this I really understand portions of webauthn that I otherwise wouldn't have.