2020 has been a challenging year. No doubt, like me, you are looking forward to the holidays. I’ve just finished all of my Christmas shopping and thought I had all the presents I needed. However, it turns out that there is one more present that I’ve been waiting for and it is courtesy of Oracle's Identity team. The latest update of our cloud identity service now includes improved support for FIDO authentication. You can read more about the announcement here.
In case you don’t know what FIDO is, it provides you a standards-based way of using existing FIDO-compatible authentication devices to authenticate to IDCS. For example, these might be external devices like YubiKeys, or they could be internal devices like Touch ID, Face ID, or Windows Hello.
With all new features, like most techies, I immediately wanted to get my hands dirty and see what configurations it takes and how easy it is to use.
From an IDCS perspective, FIDO authentication is treated just like another MFA factor, i.e., you enable it and then configure any factor-specific settings (Figure 1). So, for my IDCS instance, I enabled the FIDO Authenticator.
Figure 1- FIDO extends the existing MFA framework in IDCS
If I wanted, I could configure the specific settings associated with my FIDO authenticator. Full details are in Docs. However, I was looking for ease and simplicity, so I left all of the settings as their default options.
The only other configuration is now to decide where and how I want to use FIDO authentication. There are two main use cases supported, both of which I will configure my IDCS instance to support.
Use Case 1 - Additional Authentication Factor
The first use case involves using my FIDO authenticator as an additional factor after the user has entered their username and password.
For this use case, I use a sign-on policy to determine when the factor should be applied.
Figure 2 – Enforcing MFA within a sign-on policy
Within my sign-on policy in figure 2, I am specifying that FIDO is required as an additional, specific factor (rather than letting the user choose which factor to use). For my example in this article, I am assigning this policy to any user trying to access Salesforce through IDCS.
Use Case 2 - Passwordless Authentication
Here you use your FIDO authenticator instead of entering a password, thus delivering authentication without the need to enter a password, hence passwordless authentication.
This is configured using Identity Provider policies. Again, for my scenario, I am protecting access to Salesforce with passwordless authentication by assigning all users who are members of a particular IDCS group to be challenged directly for FIDO.
Figure 3 – Using Identity Provider policies to determine the authentication method
Now that my policies are configured, the final step is for each end user to register their FIDO authenticators. With IDCS, if the user is required to use a strong factor and doesn’t have one registered, they will be prompted to enroll one of these factors.
Figure 4 – End-user inline MFA enrolment
Alternatively, and in my case, I already have some factors registered, so I can look at My Profile and add my FIDO authenticator as a new factor. As you can see in my demo environment shown in figure 5 below, I have registered multiple different types of FIDO authenticators, including YubiKeys, Mac Touch ID, and Face ID.
Figure 5 – Registering additional multi-factor authenticators
Oracle's Identity makes it easy to enroll and use FIDO authenticators as part of your policies. In my scenarios above, I demonstrated the use cases using a couple of YubiKey 5 lightning security keys. However, I have also registered and tested Touch ID and Face ID, as well as YubiKey 5 NFC keys (with my mobile). Each work just as seamlessly as the next. If you would prefer to see my testing as videos rather than animated GIFs, you can view them here: