Built on standards that makes sign in fast and unphisable. Protect your users and make "Forgot password" a thing of the past.
Passwordless Sign In
Enable smoooth sign in using modern FIDO2 / WebAuthn
Built on standards that makes sign in fast and unphisable. Protect your users and make "Forgot password" a thing of the past.
Hit the ground running with our Passwordless API. It's the fastest and easiest way to get started and try passwordless in your app.
When you need more control and customization, you can move to our self-hosted API (coming later) or utilize the .net core fido2 library to build it straight into your applications/server.
Free
Perfect for experiments and non serious side projects
Independent developer
For non businesses and projects
Business - recommended
For businesses and SaaS apps.
Enterprise
For professional businesses
FIDO2 / WebAuthn is a modern open authentication standard, supported by browsers and many large tech companies such as Microsoft, Google etc. The main driver is to allow a user to login without passwords, creating passwordless flows or strong MFA for user signup/login on websites. The standard is not limited to web applications with support coming to Active Directory and native apps. The technology builds on public/private keys, allowing authentication to happen without sharing a secret between the user & platform. This brings many benefits, such as easier and safer logins and makes phishing attempts extremely hard.
The following chapter will explain some of the concepts mentioned in the 3 scenarios
Fido2 is the umbrella term and branding of two new w3c standards: WebAuthn and CTAP2. WebAuthn is the JS API that allows browser to talk to the operating system to generate assertions and CTAP2 is the API that allows the operating system to talk to Authenticators (usb security keys etc)
The Relying Party - often called RP - is the server that the browser communicates with. If you are a developer reading this, the Relying Party ID is probably your domain.
A FIDO2 server (a.k.a the Relying Party, RP) can ask the authenticator to verify the user. This can be done either via PIN code, biometrics or other factors that securely verifies that it's the expected human in front of the device, not just any human.
The resident credential is a credential that can be accessed simply with RP ID. When not using RK you will have to provide a list of the credentials (array of ID's) you want the authenticator to use. With RK you don’t need it because the authentication will locate all RK's (only RK credentials), and for each of them generate the assertion over the challenge and return all of them to the client. The client then will display all of the credentials to the user and user will pick one, thus returning selected credential to the relying party.