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.

Just dropping this here: https://fidoalliance.org/specifications-credential-exchange-...

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.

As a COSS founder I love the visibility we get for the issues we put on Algora. We've awarded $855 to 7 external contributors so far and are more than happy with the results. The founder team is awesome - Ioannis and Zaf are great guys and a valuable asset to the open source community.

I look forward to putting out many more bounties on Algora.

Edit: here's the link to our Algora page https://console.algora.io/org/teamhanko

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.

We’re building https://www.hanko.io

It’s a passkey-first authentication solution for websites and mobile apps.

Not quite.

Passkeys are WebAuthn "discoverable credentials", meaning they contain a user identifier as well as a private key for signing.

When a site fully supports passkeys, you are able to sign in to your account without having to enter a username, just by using your site-specific passkey (e.g. https://www.passkeys.io).

GitHub's current implementation is based on pre-passkey WebAuthn that allows you to add a non-discoverable credential as 2nd factor. To sign in, you still need to enter your username, your password, and then get prompted for your WebAuthn credential, which can be stored on a physical security key, but also on your devices via the platform authenticator capability (Windows Hello, Touch ID, ...).

So, while GitHub's current 2nd-factor WebAuthn implementation (as awesome as it is) is not "passkey", I'm sure they will be among the first bigger websites to launch full passkey capabilities on their login page pretty soon.

Hey, we've built exactly what you are describing: https://www.hanko.io

You can go with either self-hosted or cloud. Cloud is free for up to 100 users.

If you have any questions along the way: https://www.hanko.io/community

Hanko.io is an open source authentication and user management solution that is optimized for passkeys as the upcoming default login method. The frontend (login box for now, user profile coming soon) is a web component, allowing for a simple and flexible integration to websites and apps built with a wide range of web frameworks.

We decided to go with email passcodes as fallback method because of the limitations we identified with magic links. The biggest issue was the inability to sign in on devices where the users don’t have access to their email account to click the link.

With that being said, we (or someone else) may reintroduce magic links as another login alternative of Hanko though, because we also think that it is a better UX to click a link than to type a code.

In any case, our take is that the importance of the fallback auth method will diminish over time due to the omnipresence of passkey support.

For the sake of the demo, email validation has been disabled to make the account creation as simple as possible and to allow fake email addresses to be used.

Thank you for the feedback. We get this question a lot, and it is obviously not ideal right now. Things will get much better with passkey autofill very soon, though.

See also: https://github.com/teamhanko/hanko/discussions/342

At some point, the platforms may open their APIs and allow for 3rd party providers to hook in and do the syncing. It can be expected that most current password managers will do that asap.

There are very few opportunities in the wild where you can use passkeys with a real account and not just a tech demo that pops up a WebAuthn modal. We've built passkeys.io to showcase what's possible with passkeys from the perspectives of the end user as well as the service provider. The demo that you can use on the page is very much work in progress, though, and we value any feedback.

The demo in it's current state is built with a web component using shadow dom. Unfortunately, most browsers do not support autofill in shadow dom yet. A newer version using light dom will be available soon.

Email codes are just the fallback auth method in case no passkeys are supported on the device or the user has lost access to the passkeys. In real world scenarios, this may be secure enough, or fallback authentication could be disabled completely, or secured with Security Keys or other 2FA methods, depending on the use case.

It really depends on your security requirements and where you're coming from or what you're comparing it to. There would be still many advantages over, say, passwords stored in a pw manager, such as no shared secrets across all sites/apps, phishing protection, and far fewer opportunities for user errors.

Currently, only platform authenticators are supported to create passkeys with. Support for Security Keys is in development and will be available soon. Certain combinations of Linux distros and browsers will then support passkey creation as well.

Email OTP is just the fallback authentication method of the demo in case a user does not have access to the passkey(s) anymore. Depending on the real world scenario, fallback authentication may either be completely disabled as soon as passkeys are widely available, or protected by e.g. a Security Key or other 2FA methods.

By the latest definition, Security Keys also store passkeys.