FlxMgdnz

Thanks for mentioning Hanko. Data minimalism is one of our core values, so I’m really happy to see that appreciated.

Thanks for listing Hanko as EU-based authentication provider.

To be upfront about this, we’re still on AWS (Frankfurt), but "EU-owned" hosting/data regions will be available very soon.

For user authentication there is at least one European alternative to Clerk, and that’s Hanko (I am the founder).

Granted, Hanko Cloud is still running on AWS (Frankfurt), but we’re working on alternative EU data location options right now.

Thanks :)

The js SDK is almost done, mostly the docs are still missing, so I'd say 2-3 weeks. For mobile SDKs we're currently evaluating Kotlin Multiplatform, ideally that can help us manage the overhead a bit. We'd love to release them in March, but can't make promises yet. That said, the Flow API (which handles all states for you) can be used perfectly without an SDK and we have multiple customers that have done that for their production apps.

The solution to most of the author's criticisms lies in not forcibly mixing Passkeys and WebAuthn-based 2FA.

As long as you are satisfied with passkeys being "usernameless" (i.e. discoverable), you can offer a nice login flow with a "Sign in with a passkey" button and Passkey Autofill.

For 2FA use cases, you should provide a second WebAuthn configuration that does not require discoverable credentials, for example, and does not necessarily require user verification.

This allows a user to have both fully-fledged passkeys and, for example, security keys as a second factor to secure username/password-based login. Users can choose what they want to do (create a passkey on e.g. iCloud or add security keys as 2FA without using precious key storage resources on the hardware tokens).

GitHub has done a very solid implementation of that model, and we are working on adopting it to our services and it's looking very good so far.

Hey, founder of Hanko.io here, we run passkeys.io. That behaviour is not intended. We've recently changed the demo to require authenticator attestation on passkey creation, that may have an impact on authenticator selection. But a quick test on my system (macOS, Chrome) resulted in the 1Password UI intercepting the "Create a passkey" flow - as expected. It would be awesome if you could help us understand why your experience is different.

With that being said, we are not happy with how password managers have implemented passkey intercepts, but ultimately that's a decision the user can make, as it can be disabled in the browser extension settings.

Thanks for posting the link. Founder of Hanko here, happy to answer any questions on passkeys or Hanko Auth.

Hey, quick note from the creator of passkeys.io: You can always enter your email address on the login screen and this will initiate a fallback auth flow via email passcode.

Such an identity provider does not exist unfortunately, at least not with enough users to justify an integration for you. Of course you can always set up your own SSO provider (with the tools listed in AHOHA's comment), but that one would be limited to your own user base.

I'd propose you take a look at passkey, which allow for a very convenient, but privacy-friendly alternative to social SSO.

You can even combine social SSO with passkeys. Then users could sign up to your sites with one click through Google or Apple, but any subsequent login can happen between you and the user with a passkey. That's how we are doing things at hanko.io

Apple, Google, and Microsoft are working together closely on passkeys.