A working implementation library + demo for FIDO2 and WebAuthn using .NET.
Bringing FIDO2 & WebAuthn to asp.net, .net core and full framework.
Passwordless
Enabling smoooth sign in
A working implementation library + demo for FIDO2 and WebAuthn using .NET.
Bringing FIDO2 & WebAuthn to asp.net, .net core and full framework.
Enable passwordless sign in for all .net apps (asp, core, native).
To provide a developer friendly and well tested .NET FIDO2 Server / WebAuthn relying party library for the easy validation of registration (attestation) and authentication (assertion) of FIDO2 / WebAuthn credentials, in order to increase the adoption of the technology, ultimately defeating phishing attacks.
FIDO2 / WebAuthn is a new 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. Read more: Why it's exciting Medium FIDO Alliance Yubico WebAuthn.Guide from Duo Security WebAuthn.io WebAuthn Awesome
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 is probably your webserver. It's the server that runs the fido2-net-lib library.
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.