Cloud Identity

FIDO2 Conformance – why it’s a big deal

Share this post:

I was fortunate to recently find myself amongst the first round of server vendor participants to take a product through FIDO2 certification, and that’s what today’s article is really all about. IBM’s authentication platforms, which include both on-premise (ISAM) and cloud-based (IBM Cloud Identity) offerings, are the perfect vehicle to bring this new era of strong authentication technologies to your business. Expect to see this technology appear in our commercial offerings soon. My advice – start learning about it now! In this article I will outline some of the history of web authentication – the journey that got us here, and demonstrate scenarios that are now possible with the FIDO2 and WebAuthn standards.

Problem statement

Anyone in the IT security game knows that password authentication is out of flavour. It’s almost a taboo subject. The reasons are simple – passwords represent copiable, easily remembered and almost always re-used keys to our increasingly critical digital kingdoms, both personal and professional.

The problem is amplified because of the nature of people and the human brain. People compete with (i.e. actively try to circumvent) the arcane policies dictated mostly by security “experts” in their places of employment, such as:

  • make your password complex and include non-alphanumerics (who doesn’t use one of ‘!’, ‘@’ or ‘#’ which are the most convenient first three punctuation chars above a US-keyboard?)
  • make them long (ok that’s easy)
  • expire them (just another dumb idea – people just increment the numeric part of their password or switch between well-known patterns until they break the authentication system’s “not like the last few” rules)
  • don’t re-use them (I love this one, it’s completely un-enforceable across disconnected authentication systems)
  • have a minimum expiry period (I love this one too, it’s designed to stop people from iterating through password changes till they get back to the one they started with. It’s also easily circumvented by a forgot-password reset flow in most cases)

Get the idea yet? Passwords are bad because people are required to remember them, or write them down, or use a digital password manager (which almost always doesn’t port across all the platforms and devices you use and has risks, and a password, of it’s own). The policies are ineffective because people are continually just finding ways to work around them for their own convenience.

Second-factor and alternative-to-password authentication options

Enough of this rant – what is the world doing about it? Well, that is part of my job. For several years many of us in the IT security industry have been working on and delivering 2nd-factor and strong authentication solutions for digital systems of human engagement, including web and mobile. These were initially mostly second-factor systems (think SMS OTP, email OTP, TOTP, FIDO U2F). The reason they are 2nd-factor systems is that you first need to be aware of who the user claims to be, with some basic level of assurance such as their password, so that you can lookup their phone number, email address, TOTP secret, registered public key credential, etc to initiate the strong-authentication portion of the login process. This works fairly well, but still has a password to get things under way which is a little inconvenient for the user.

Enter the world of alternative-to-password first-factor authentication. Some environments have been capable of doing this for years – one example is the PIV/CAC cards used in the US federal space. In their traditional physical form these work well but require bespoke hardware to use and have costly provisioning and lifecycle management processes.

The mobile platform has afforded new opportunities for alternative-to-password authentication too, and I have blogged about one that we have done at IBM already: Password-less login with IBM Verify. Ultimately this relies on the user implementing reasonable user-to-device security controls as well as maintaining physical possession of their phone.

FIDO2 is the next generation of affordable, portable, bring-your-own, standards-based alternative-to-password authentication. When combined with WebAuthn, which is a W3C specification focused on standardised javascript APIs for browsers to interact with authenticators, we start to get a pluggable ecosystem for strong user authentication on the web. Way back when the web was a baby in the early 90’s, basic-auth was the first such “breakthrough” standards-based way of authenticating users. All the major browser vendors implemented it, and humans figured it out. Well WebAuthn+FIDO2 is promising to bring the same level of cross-platform and cross-browser standardisation for strong authentication on the web as basic-auth did for regular username/password authentication.

And it’s real.

Let’s take a look at an example use case that is now possible, and explore the components involved.

Example Scenario

A retail bank today offers internet banking via a browser-based web application. The existing user authentication experience is:

  1. Login with a username and password, then
  2. Receive an OTP via SMS on their registered mobile phone for 2nd factor
  3. Enter this OTP on the web page, and then you are logged into the internet banking application.

In the new model, the retail bank allows the user to register any compliant FIDO2 resident key authenticator. This registration occurs one-time under the context of a legacy authentication, or as part of initial account establishment (meaning the user never had or will ever have a password for their account). The new user authentication experience on opening their browser at the banking site is:

  1. See a prompt to authenticate with a previously-registered FIDO2 authenticator.
  2. Perform a user-verification action or gesture (this step varies based on authenticator capabilities) and you are logged in.

That’s a lot better. In the rest of the article I’ll take you through a shallow dive of the components involved in this type of architecture, and provide some advice for getting started.

FIDO2 Technology Components

I thought it might be useful to seed your own educational journey with my own high-level description of the components involved in a WebAuthn+FIDO2 authentication scenario such as the one mentioned above.


Authenticators are essentially user-owned devices or components that use asymmetric key technology to prove possession of a private key by signing server-generated challenges. There’s more to it than that (such as ensuring that different key pairs are generated for privacy reasons during every registration), but that’s good enough for a high-level understanding.

At registration time, the server sends a generated random challenge, via the browser, to the authenticator. The server actually also tells the authenticator who is registering. This is a key difference between FIDO2 resident keys and FIDO U2F second factor. The authenticator responds with both the signed challenge and the public key able to validate the signature (and other information used for attestation described later). The public key is registered against the user’s account at the server. On subsequent authentication flows, the server send a newly generated challenge to the authenticator, and validates the returned signature using the same public key previously registered for the user.

Authenticators are loosely grouped into two categories – platform authenticators, and portable authenticators.

Platform authenticators are, as the name suggests, those that are somewhat built-in to the operating system platform where the browser is running. Examples that I have used at the time of writing this article include Microsoft Edge with Windows Hello, Chrome+TouchID on a Mac, and Chrome on an Android phone using the existing user-to-device security set up by the user (swipe pattern, fingerprint, device pin, etc).

Portable authenticators include security keys in form factors that communicate with the browser via USB, BLE (Bluetooth Low Energy) or NFC. Some include fingerprint readers for user verification. Others do user verification via only a simple PIN. Some even have small screens to display information to the user during the authentication process. I’ve even seen and used wearables that have FIDO2 strong authentication capabilities built in.

Either way, the user can (with privacy and safety in mind) register and then later authenticate using one of these user-verifying authenticators at any site that supports WebAuthn. The authenticator is either part of your device, or in the case of a portable authenticator typically cheap enough that the bank might give them away as a promotion, or the user’s may just buy them standalone. For backup and redundancy, a user should be encouraged to register multiple such authenticators against their account, perhaps the built-in platform authenticator on their laptop, plus a portable authenticator they keep in a safe place in the event of laptop loss or failure. The authenticator may be used solely for 2nd-factor authentication scenarios, however I think the high-value experience is when the authenticator is used as part of a completely alternative-to-password strategy. This latter scenario requires use of authenticators that support a FIDO2 concept called Resident Key Credentials. All of the platform authenticators I have seen support this, and most new FIDO2 portable authenticators do too. A few do not, and U2F-only authenticators do not, so watch out for this if you want alternative-to-password authentication and are looking at what authenticators to use.

Web Browsers

The entire technology flow requires servers to send HTML pages to browsers that contain embedded Javascript that calls WebAuthn API’s to interact with authenticators. Browser act as a trusted conduit between the authenticators and the server. My experience so far with browsers that support WebAuthn includes Microsoft Edge (on Windows 10 RS5 insider preview), Chrome (both GA and Canary versions), and Firefox (GA and beta versions). Each have their own nuances and differing maturities of support of the standards (a point in time statement), but all can and do work with a variety of authenticators. It is clear these browser vendors are committed to WebAuthn now that it has become a protocol being worked through the w3c standards body. That’s a very good thing, and is one of the key reasons I think this technology is now going places and will soon become widespread.

Servers and Attestation

Servers, including IBM’s access management products, need embedded technology to understand the FIDO2 messages and the WebAuthn APIs and manage the lifecycle of public key registrations for users’ accounts. To be flexible in the commercial sense, they also need policy engines that can be configured by administrators to decide if certain brands or types of authenticators are even acceptable for use at this site or for specific step-up authentication scenarios.

This process of vetting the authenticator characteristics is called attestation. In traditional client certificate authentication to a website, administrators whitelist CA certificates in a trust store and use PKIX chain validation including OCSP or CRL’s for revocation. This is attestation – making a determination about trust. It is no different than the physical attestation that occurs in transactions people do in everyday life.  When you buy a house or other high-value item, you make sure that the seller is really the current owner, is entitled to sell you the item (doesn’t have outstanding mortgages), and that it is guaranteed to be free from contamination or other de-valuing defects. That is also attestation.

In the FIDO2 authentication landscape, there will be high security scenarios for which it is essential that security administrators consider the merits of different authenticator vendors and decide what authenticators are permitted for use at a site, or under particular transactional circumstances. There is an entire process to consider around attestation and the FIDO2 ecosystem provides mechanisms (called metadata) for doing just this.

Make sure that attestation capabilities and authentication and authorization policy engine integration are a key part of your evaluation process when looking at servers.

If you are interested in reading more about the pro’s and con’s of attestation, I do recommend these articles which I found very informative, and discuss it in much more detail:

Take action – read more, and go try it out

I am a firm believer that this technology and the subsequent fast, fun and safe user authentication experience that it offers is a vital part of a larger multi-modal set of alternative-to-password authentication strategies that our customers should consider. WebAuthn and FIDO2 authentication aligns well with IBM’s access management strategy for both on-premise and cloud adoption patterns.

If you would like to start experimenting with the capabilities from the end-user perspective today, we have a demonstration playground where you can give it a go:

Also take a look at the FIDO announcement for a list of conforming authenticator vendors, or reach out to your IBM technical sales representative who can put you in touch with me or one of the other folks here at IBM and we will be happy to show you how to get started.

More Cloud Identity stories

IBM Security Verify Access: Remember Session – an advanced use case

IBM Security Verify Access version is now out the door. Among several new features is the Remember Session capability in the Web Reverse Proxy (WRP). This feature delivers to the browser either via persistent cookie or a HTTP response header an encrypted token which represents the username and (a configurable list of) attributes of […]

Continue reading

RIP epac.jsp (2007-2020)

It has been some time since I last wrote about new capabilities in our on-premises access management offering (formerly IBM Security Access Manager, now IBM Security Verify Access). In this article I’m going to share some history, and discuss one of my favourite recently added capabilities – something I personally asked the development team to […]

Continue reading

Protecting entire ISAM WebSEAL site with multi-factor authentication using stepup login

Today I’m going a bit old-school with information on a basic ISAM scenario that has been available for years. This has come up in field questions several times recently, I think mostly with people who are relatively new to ISAM but understand the need for multi-factor security as a standard part of the authentication workflow. […]

Continue reading