f-23 / react-native-passkey

Passkeys for React Native
MIT License
121 stars 25 forks source link

Suggested WebAuthn Server #11

Closed andrew-levy closed 1 year ago

andrew-levy commented 1 year ago

Hey, not really an issue but more of a clarifying question since I think this library is going to become really important as passkeys gain steam.

My team recently built an ios, android, web, and backend implementation for passkeys separately, and the most challenging part was making sure the format of the result (like the register or auth result) matched up with what the webauthn server was expecting. We used Yubico as a starting point i believe and, for example, on ios i needed to do a lot of base64url converting (and back) and making sure that all properties of the result objects were there. the web has https://github.com/github/webauthn-json to ensure the format is correct, but had to do it manually for ios and android.

So my question is, should the handoff between client and sever be the responsibility of the developer? or should this library be more opinionated in this and add suggest a specific server?

f-23 commented 1 year ago

Hi, that's an interesting question. As of now the responsibility is on the developer to make sure the handoff between client and server is working as expected.

I'm working on Android support for this library right now and the androidx credentials library used under the hood differs quite a bit from the native iOS Passkey API in terms of input and output format. On Android it takes in requests formatted as JSON strings. On iOS we need to pass in each request parameter as a separate argument. That's why I think the easiest way to combine these two is to change the JS function inputs to directly take in the registration/auth requests from the server as JSON and also return them in JSON format, then throw an error in case the requests don't match the WebAuthn standard. That way we can just pass in that request straight away on Android, for iOS we can convert and pick out the required params first. That would create a more streamlined dev experience and be more in line with the WebAuthn standard as well.

Thoughts?

andrew-levy commented 1 year ago

I think this is the right approach. Thanks for the thoughtful reply!