Recently, folks at Asgardeo released a new feature called the Asgardeo Try it Application for quickly testing various login flows effortlessly. The best part of this feature is that you don’t even need a functional application to get started with Asgardeo. How crazy is that, huh?
Alright, now let’s get into it.
Getting started
When you first log in to the Console application using your tenant admin credentials, it will present you with the following landing page.
Once created, it will immediately redirect you to the Try it application. But for now, you can close that tab and head back to the Asgardeo Console.
I already have applications, but where’s Try it? — If you have accidentally deleted the
Try itapplication, don’t worry. You can recreate it from the Getting Started Page once again. Then Asgardeo will prepend a fresh copy to your existing application list.
Configuring first-factor auth
In every application, you’d either have email/password, social or entirely password-less authentication. Well, lucky for us; Asgardeo has all these options baked-in, so we can nibble instantly. I’ll configure some social connections along with email & password and biometric authentication. You can refer below video for adding first-factor authentication to the Try it application flow.
Connections configuration
I already have Google & GitHub connections configured, and they are available for me to add to this application. However, if you don’t see them, you should refer the official Asgardeo documentation on configuring social connectors or refer to my previous article about Asgardeo JIT User Provisioning for a quick tutorial.
Add a user
Also, note that I have created a Customer User in my default user store. You can easily do this by navigating to the Manage > Users section by clicking the + Add User button. Or you can refer official Asgardeo documentation on how to add users.
Okay, now we have the first-factor authenticators; it is time for us to Try it! We can instantly try this out by clicking the “Try Login” button.
Alright, you’ve got me! — You saw that I’m not trying out Biometric Authentication (the last login option) because it requires setting up using the self-care portal before we can authenticate users. And on the other hand, I want to expand a bit about Asgardeo’s Security Key / Biometrics authenticator in this article.
Also, if you’re using an Apple Chip, there’s a hint mentioned on making it work in Asgardeo in a password-less fashion using an iPhone & XCode written by Thamindu. Regardless, Asgardeo will seamlessly function with any functional FIDO2-compliant device on the fly.
Security key and biometrics 101
Asgardeo lets you configure FIDO2 compliant devices to enable password-less authentication for your Users. In the above figure, we configured it in the first-factor configuration, and you can see that we can easily attach a FIDO authentication to the authentication sequence’s first step.
What’s FIDO anyways?
FIDO (Fast Identity Online) is a set of open, standardized authentication protocols that ultimately eliminate passwords in application authentication developed by the FIDO Alliance open industry association intended to ultimately eliminate passwords, which are often ineffective and outdated from a security perspective.
Usually, when using FIDO, completing an initial registration process, and selecting a preferred method, your users can authenticate to your application by simply providing a Fingerprint, Voice, FaceID, Security Key or entering a known PIN, depending on the technology available on their computer or smartphone.
How does it work underneath?
FIDO protocols use standard Public Key Cryptography techniques to authenticate users, which means that all communications are encrypted. Ultimately the private keys and biometric credentials never leave the user’s devices.
What are the types of protocols?
The FIDO Alliance has published three sets of specifications, and they are standardized on public key cryptography and namely: -
- Universal Authentication Framework (UAF)
- Universal Second Factor (U2F)
- FIDO2
What Asgardeo Supports?
Currently, Asgardeo supports FIDO2 and Asgardeo implements the newest set of specifications. These specifications are born through a joint effort between the FIDO Alliance and the World Wide Web Consortium (W3C).
FIDO2 is implemented with two open standards. And they are the FIDO Client To Authenticator Protocol (CTAP) and the W3C standard WebAuthn. These two work together to provide users with password-less authentication experiences or two-factor and multi-factor authentication experiences if additional protection is needed.
Available Specifications
They are different sets of user experiences that involve Advanced Platform Authenticators, like Biometrics (FaceID, TouchID) or PINs, and Roaming Authenticators, like Key Fobs or USB devices.
The specifications included in FIDO2 are: -
- WebAuthn - This defines a standard web API built into platforms and browsers to support FIDO2 authentication. It provides an interface for creating and managing Public Key credentials and can communicate with CTAP1 and CTAP2 authenticators.
- CTAP1 - This is the new name for the FIDO U2F protocol. It provides users with a second-factor authentication experience, which requires that they plug security devices into their computers, or tap their devices near an NFC reader, to gain access to the application.
- CTAP2 - This allows the authenticator to be used as both the first and second-factor authentication and can provide users with password-less authentication experiences or 2FA and MFA experiences if additional protection is needed.
So here’s how we configure a device as a first-factor biometric authentication (I don’t have a proper Fido2 key, but my machine can act as a biometric authenticator).
The following illustration is the initial authentication flow users go through to set up their devices for authentication using the Asgardeo’s My Account self-care portal.
Asgardeo docs also mention that we can configure FIDO2 password-less login for our application using two primary methods: -
Security key/Biometrics: An application user uses a FIDO2-supported authenticator to log in without entering a username or a password.
Identifier first + Security key/Biometrics: An application user enters a username first. Asgardeo verifies the identity from the username and prompts the user to use a FIDO2-supported authenticator to log in.
Oh, Small Hiccup 🥺
We can only use the
Identifier Firstauthenticator along with theMagic Linkauthenticator. Asgardeo forewarns us before we update the authentication steps saying that using it with any other authenticator can lead to unexpected behaviours.
Anyhow, the documentation says this method will be available shortly in Asgardeo. Until that, you have to stay tuned.
Configure second-factor auth
Asgardeo allows us to add second-factor authentications such as TOTP and Email OTP to
the Try it application’s authentication flow.
How convenient!
Guess what? It doesn’t require additional configurations to test it. We can directly jump into the playground.
Hmm, something is odd
We have configured second-factor authenticators, but we haven’t considered the user experience of these authenticating options. Usually, when we configure multi-login options (i.e., email/password along with social connectors), it is best practice to avoid 2FA when a user authenticates from a federated connection. Here’s why: -
When you log in through Google/GitHub connection, it usually prompts a notification on a device or email asking for validation whether only you are trying to log in (i.e., one-tap popups, mobile OTP code etc.). Now assume you completed either one of those.
If everything goes as expected, then the flow is validated by Google. So, it doesn’t make sense to initiate another 2FA/MFA verification in Asgardeo if you sign in using Google, correct? If we do that, it leads to a poor user experience. So, how can we fix those without making those mistakes in production?
Well, lucky you, Asgardeo has thought about this already!
Adaptive authentication to the rescue
In Asgardeo, every application has its adaptive authentication script to manage its
authentication flows. This script allows you to enforce adaptive MFA in the login
flow of your applications. For example, you can control authentication based on Group,
Sign-in-option, New-device, IP, and API calls.
We are particularly interested in the Sign-on-option based script, where we can conditionally
skip 2FA for Google and GitHub. The great thing about Asgardeo is that you can directly
test it within the Try it application. It mimics what a user would go through,
and you can deploy your application to production with finesse!
var localAuthenticator = "LOCAL";
var onLoginRequest = function (context) {
executeStep(1, {
onSuccess: function (context) {
var step = context.steps[1];
if (step.idp == localAuthenticator) {
executeStep(2);
}
}
});
};Just turn on the Conditional Authentication switch and paste the above code snippet like the following: -
Once you update the script with the above, you can verify that Asgardeo skips TOTP and Email OTP
for FIDO and Social Connectors.
Well, now that we have covered the customization of Sign-in Methods in this Try it
application, we are only left with the User Attributes and Advance Settings to cover.
Other settings
User attributes
Specifically, the user attributes are pre-configured for the Try it application as it is a static
application that aims to test the login flows. However, we can
enable and configure additional user claims/attributes after
integrating our actual application to Asgardeo.
Advanced configurations
Asgardeo allows you to control and test the User consent screen rendered during the
sign-in and sign-out flow in an application. You can refer the
official Asgardeo documentation on user consent management
for more information. The best part is that you can do this in the Try it application.
Well, now you know how to try out Asgardeo without an application. Asgardeo makes testing and experimenting with complex logical authentication flows in the application effortless.
Thanks a bunch for reading 🥰!