Register/login with fingerprint or face recognition as a service. Idea, concept & screenshots.

Before going into details, let me say that what is presented here is not yet available. It is a project in the early stages.

What is it, and why?

This project is meant to be a "universal passwordless platform". It is there to register/login users without using passwords but rather biometrics, security keys or device PIN codes. The goals are threefold: a smoother user experience, improved security and ease of use for developers. The whole packaged as a free public service, backed by sponsorships. Ideally.

What does it look like?

Since a picture is worth a thousand words, let me first illustrate the concept using screenshots before I delve into more details. Please keep in mind that all of this might change and is in early conception phase.

When the user lands on the main page, it will be prompted to login/register.

This login/registration interacts with the device the user currently uses and request biometrics or device PIN.

Note that these biometrics do not leave the device. The biometric/PIN of the device enables cryptographically signing a message to prove its authenticity.

In other words, only the registered device can also be used to login. That is why a recovery option should be selected upon registration.

Once done, you land on the profile page or are being redirected to the original website page.

Naturally, you can also edit the profile and many other settings.

Instead of having the user register for every website separately, the plan of this platform is to centralize the authentication, so that users only have to register/login once and for all. Any website could then simply request access the user's profile (if the user allows it of course).

Of course, some users might use devices not supporting biometrics or the necessary protocols. In this case, a fallback to a more traditional login would be provided.

This roughly outlines the usage from a user's perspective.

How does it work technically?

It builds upon a fairly recent browser protocol: webauthn. You can read about it in my posts here: https://dev.to/dagnelies/series/16859

Basically, upon registration, the browser will access the device and request the generation of a public/private key pair. The public key will be sent to the server in order to prove authenticity of future logins.

The private key on the other hand is kept locally on the device, protected by either biometrics or PIN code. Logging in is then simply proving you are in possession of this private key by signing a challenge.

This protocol is the cornerstone of this new registration/login experience.

Improved security

This is basically two factor authentication in a single step. The first factor is something you have (the device) the other is something you are or something you know, depending on whether biometrics or PIN code is used. Please note that unlike traditional logins, only your registered devices can login.

The passwordless approach also make phishing attacks ineffective. There is simply no password to steal. Moreover, stealing the private key is impossible since it is never exposed. It is used to sign messages.

The same goes for password re-use and breaches. They both become ineffective.

Is it bullet proof security? Well, everything has its limits. For example, if a third party website gets hacked, the personal information it accessed risks of being leaked too. That is something impossible to prevent. On the positive side, your account will not be compromised. It will be impossible for the attackers to login into your account since the private keys remains on your device, protected by biometric/PIN.

What about privacy?

This is meant to be a centralized identity platform. In order to avoid the user to create yet another account, and register the device yet again, it is meant to be a global identity.

In other words, all other websites/services could simply ask permission to read your profile or parts of it (like only the nickname for example). This one account/profile of yours will be used for all websites/services.

As such, privacy is very important. Sometimes, you want to visit a website but do not which to share personal information. In order to do that, every user can select which information it wants to share or hide as seen in the beginning.

A potential feature would be offering website specific nickname aliases as well as anonymised e-mail forwarding for further anonymity without the need to switch accounts. But that would be rather down on the roadmap IMHO.

Nice! How do I use that?

Well, you can't, it's not yet built. However, it is planned to be super simple.

Basically, a single request in the browser GET /profile?require=nickname,email is sufficient to obtain the profile as JSON.

{  "user_id": "tJDvC28ruOddtAChdclt...",  "nickname": "Johny",  "email": "[email protected]",  ...  "session_id": "ytEA6IE67FE0zeRv6rAp"}

And if a HTTP 401 - Unauthorized is obtained, just redirect to the platform to let the user register/authenticate. Once done, it will return to your website page. The profile call will be repeated and succeed.

I hear you: "Yeah, but... I need to be sure of the user's identity on the server side!"

No problem! From your frontend, you could send requests with session_id to indicate the user session. Then, in your API backend, just call GET /profile?session_id=...&origin=mywebsite.com.

Since it is impossible to guess session_id, it is safe to assume it is a real user session. It is a proof of authentication. Moreover, please note that each website (origin) will obtain its own session_id. When requesting the profile, it is also verified that the origin matches the session_id to ensure that it is not a user session from another website.

So... What do you think?

Thanks for reading all that. I would love to hear your feedback.