# Asgardeo try it application
> Learn how to use Asgardeo Try it Application to test out various authentication flows.
September 6, 2022 · 9 min read · https://yasint.dev/introducing-asgardeo-try-it-application/
Tags: identity, iam, asgardeo
---
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 it` application, 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](https://wso2.com/asgardeo/docs/guides/authentication/social-login) or refer to my previous article about [Asgardeo JIT User Provisioning](https://www.yasint.dev/asgardeo-jit-user-provisioning#activate-federated-connections) 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](https://wso2.com/asgardeo/docs/guides/users/manage-customers/#onboard-a-user).
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](https://wso2.com/blogs/thesource/fido-passkeys-with-asgardeo/) written by [Thamindu](https://lk.linkedin.com/in/thamindu-dilshan-jayawickrama). 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](https://fidoalliance.org/overview/)
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](https://en.wikipedia.org/wiki/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](https://fidoalliance.org/overview/)
and the [World Wide Web Consortium (W3C)](https://www.w3.org/).
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](https://wso2.com/asgardeo/docs/guides/user-self-service).
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 First` authenticator along with the `Magic Link` authenticator. 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_!
```js hideLang isWindow
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](https://wso2.com/asgardeo/docs/guides/authentication/user-attributes/enable-attributes-for-oidc-app/#select-user-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](https://wso2.com/asgardeo/docs/guides/authentication/manage-consent-for-attributes/#get-consent-for-user-attributes)
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 🥰!