Passwordless
Last updated
Last updated
Passwordless authentication requires an enterprise licence. Please contact support.
Passkeys are a modern replacement for authentication methods like usernames and passwords. In the best case scenario a user should create unique credentials for each website or system. The advantage of using unique credentials is, that not all accounts are compromised when an attacker get access to a password, e.g. through a phishing attack or data leak. But this leads also to the problem, that by the rising number of passwords and the length of sufficiently secure passwords, it is hard for a user to remember those, if they are not using password managers or other tools.
Passkeys leverage the user authentication to a passwordless level. They enable users to log in at websites or applications with fingerprints or face scans, for example. In the background complex mechanisms handle the authentication using public-key cryptography. The system will create unique key pairs for each service and distribute only the corresponding public key at creation time. Since the keys are automatically generated, the keys are more secure than a manually created password which may be too short and simple. When using passkeys instead of passwords, users not only benefit in terms of security but also in terms of comfort.
The development of passkeys and its specifications are driven by the Fast Identity Online (FIDO) Alliance, an open industry association built of many international tech companies. As the name suggests, the FIDO aims to improve online authentication by eliminating the dependency on passwords and establish superior authentication methods like passkeys.
Passkeys are built on public-key cryptography and originate from the FIDO2 specification, whereas FIDO2 is built of the Client to Authenticator Protocols (CTAP) published by the FIDO Alliance and the Web Authentication (WebAuthn) specification standardized by the World Wide Web Consortium (W3C). The FIDO2 specification enables users to authenticate without passwords using embedded authenticators, e.g. like a fingerprint reader on a smartphone, or external authenticators. An external authenticator can be a token connected via USB or a smartwatch connected via Bluetooth. The protocol which is used to communicate with external authenticators is CTAP in version 2, also called CTAP2. WebAuthn is the definition of the JavaScript API which is built into modern browsers.
The figure above illustrates the different actors of the specification. In general the flow of an authentication can be described as followed:
A user opens the website owned by the relying party, i.e. the service provider.
The JavaScript application provided by the relying party utilizes the WebAuthn API calls which are built into the browser: navigator.credentials.create() or navigator.credentials.get(). It will pass information fetched from the relying party like a unique challenge, the origin of the website and the ID of the relying party and other options like the requirement to create a discoverable credential aka passkey.
The underlying operating system will prompt the user to choose from different, available methods: use an external authenticator, like a smartphone or use an internal authenticator like Windows Hello
After the user decided which authenticator to use, the authenticator will eventually ask for user presence (e.g. touch a button) or user verification (e.g. fingerprint)
Based on the type call (create() / register or get()/ login) the authenticator will do one of the following operations to create the response:
Register: a new private and public key pair is generated and the public key is placed in the response object. The private key will remain secure in the authenticator.
Login: the challenge created by the relying party will be signed with the private key saved for that relying party and the signature will be returned.
The authenticator will return the credential object back to the JS API caller
The response from the API call will be sent to the relying party
The relying party will create a user, for example, and saves the transmitted public key for future validation in a registration scenario. If a user exists and a login is perfomed, the corresponding user object is retrieved from a database, for example, and the public key is used to verify the transmitted signature.
WebAuthn defines two types of credentials: non-discoverable aka server side credentials and discoverable credentials. Passkeys are discoverable credentials. Read more
Passkeys contain the userHandle, or ID, in the authenticator. All authentication is performed on this type of identification and therefore no username is required to use.
