For developers with existing web pages or applications that are looking to implement FIDO Authentication there are two changes that you will have to make to your application: 1) modifying the login and registration pages of your website or mobile application to use the FIDO protocols; and 2) setting up a FIDO server to authenticate any FIDO registration or authentication requests. The next two sections give a high-level overview of the steps to take for both of those changes.
Modifying Register and LoginAssuming your application already has the ability to register and login to accounts, adding FIDO Authentication is as simple as modifying your register and login screens. The first design decision to make is whether to use FIDO for first factor authentication (password-less) or second factor authentication. There are too many considerations that go into that decision to discuss here (ease of use, platform availability, application type, risk tolerance, etc.), but the good news is that regardless of whether using FIDO for first factor or second factor, the implementation looks roughly the same.
RegistrationIntegrating FIDO with your registration web page is as simple as calling the right registration API call. The registration calls for each FIDO specification are:
- UAF: UAF_OPERATION (iOS, Android) — The UAF Client API specification defines an Android Intent and iOS x-callback scheme (respectively) with an operation type of UAF_OPERATION, where one of the first arguments to the UAF_OPERATION tells the authenticator to perform registration.
- FIDO2 / WebAuthn: navigator.credentials.create() — The WebAuthn specification (which is part of the FIDO2 project) defines a the navigator.credentials.create() API for creating a new credential (a.k.a. – registering) in a browser.
- UAF: the UAF Protocol specification defines how a server should process and validate registration requests and authentication (a.k.a. – login) requests
- FIDO2 / WebAuthn: the WebAuthn specification lays out all the steps that a relying party / server should perform when receiving a registration or login requests.
Log inLogging in with FIDO is very similar to registration. Just like there is a registration call for each FIDO specification, there is a similar log in API:
- UAF: UAF_OPERATION (iOS, Android) — The UAF Client API specification defines an Android Intent and iOS x-callback scheme (respectively) with an operation type of UAF_OPERATION, where one of the first arguments to the UAF_OPERATION tells the authenticator to perform login.
- WebAuthn: navigator.credentials.get() — The WebAuthn specification defines a the navigator.credentials.get() API for using a credential (a.k.a. – logging in) via a browser.
Adding a FIDO ServerThere are far too many ways to integrate a FIDO server with existing authentication flows to cover them all comprehensively here. For example, a FIDO server may be integrated with your web or application server, may be provided as a module within an existing IAM framework, may be a stand-alone server, or for very broad and complex services it may be any combination of the above. Also, FIDO may be integrated with an application-specific user data store (such as a MySQL or Mongo database), with LDAP / ActiveDirectory, provide SSO through an OpenID Connect (OIDC) identity provider (IDP), etc. The wide variety of back-end authentication architectures and use cases makes it difficult to talk about all the details of FIDO server integration, so what follows are generic tips and considerations for FIDO server deployment. Specific server vendors and their documentation should add additional information about how to integrate FIDO into any pre-existing IAM environment. Aside from setting up the hardware and software for your server, there are several steps that are common across most server deployments:
- Servers will typically use REST endpoints to communicate with clients. This will require proper firewall configuration to communicate with clients. As mentioned previously, these endpoints may be part of existing applications (such as web servers or mobile application servers), or a micro-services architecture or ESB may be used to route messages to a stand-alone FIDO server.
- Servers require https communication, so they will need a valid TLS certificate for https (or, will require a TLS terminator in front of them).
- Servers may have policy configurations for determining when to allow registrations and authentications. For financial or government institutions, this may include use the FIDO Metadata Service (MDS) to validate the security of authenticators that are accessing services.
- Servers will need to integrate with some form of user data store (LDAP, ActiveDirectory, MySQL, MongoDB, etc.). For new services, this is simply a matter of having some kind of storage associated with each user’s account. For existing applications, this will require modifying data schema — typically adding some form of one-to-many relationship between user accounts and the authenticators / credentials that they will register.