Google Introduces Passkey Authentication

Re:Google Introduces Passkey Authentication by awinter-py on Thursday May 04, 2023 @05:12PM (#35822138)

can someone who understands the cryptographic basis explain how centralized this is?

it sounds like an app can consume passkey logins without registering with a provider?

do providers phone home when I log in? can providers block an app from using them?

can I self-host a provider, or is there a shortlist of approved providers?

is there any provider that allows me to backup private key without sending it to their cloud?

is it similar to openid in that it shares email etc with the app on login?

[ Parent | on HN ]

Re:Google Introduces Passkey Authentication by cma on Thursday May 04, 2023 @05:18PM (#35822221)

It will really be a shame if we got ssh-like public key authentication for the web, but can't self-host it.

[ Parent | on HN ]

Re:Google Introduces Passkey Authentication by awinter-py on Thursday May 04, 2023 @05:38PM (#35822428)

main gripes about oauth / openid are you phone home to the provider on every login, and the protocol is sufficiently nonstandard to be bad for self hosters

like if you want to use oauth to access your own google calendar, you have to go to the developer console, draw a pentagram of week-old chicken's blood that has turned dark, create an entire new cloud project, incant backwards latin, etc

per:

1. https://docs.simplecalendar.io/google-api-key/

2. 7 steps and 6 scopes to use dav https://developers.google.com/calendar/caldav/v2/auth

3. https://support.google.com/googleapi/answer/6158862?hl=en

[ Parent | on HN ]

Re:Google Introduces Passkey Authentication by kdbg on Friday May 05, 2023 @03:16PM (#35833920)

First, just a high-level overview over how it would work as an app/consumer which is not terribly centralized outside of requiring browser support:

Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store.

For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed.

---

So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it.

So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.

[ Parent | on HN ]