Hands-On IAM with WSO2 Asgardeo: Configuring SSO, MFA, and Adaptive Authentication

Why I wrote this

What is WSO2 Asgardeo?

Part 1: Setting Up the Foundation

Task 1: Create an Asgardeo Account and Access the Console

Task 2: Register the Try It Application

Part 2: Authentication Configuration

Task 3: Add Google as a Social Login Option

Task 4: Enable Self-Registration

Task 5: Enable Password Recovery

Part 3: Security Hardening

Task 6: Custom Branding

Task 7: Configure Email OTP as a Second Authentication Step (MFA)

Part 4: Adaptive Authentication Script (the interesting part)

Part 5: Testing Everything End-to-End

New User Registration

Login with MFA (Username and Password)

Password Reset

Google Login and the Adaptive Script in Action

Summary: What Each Feature Does

Why This Matters for DevOps and SRE A real walkthrough of every task from the WSO2 DevOps training program assignment As part of the WSO2 Linux System Administration and DevOps Engineering Training Program, I recently completed a hands-on assignment using WSO2 Asgardeo. The task covered everything from basic account setup to writing adaptive authentication scripts in JavaScript. This post is a full walkthrough of what I configured, how each piece works, and the parts I found genuinely interesting along the way. If you are new to Identity and Access Management (IAM) or just want to see Asgardeo in action before trying it yourself, this should give you a clear picture. Asgardeo is WSO2's cloud-native Customer Identity and Access Management (CIAM) platform. Instead of building login pages, registration flows, password recovery, and multi-factor authentication yourself, Asgardeo handles all of it through a single console. For DevOps and SRE engineers, this matters because you are often the person responsible for securing internal tooling, managing service accounts, or setting up SSO for platforms like Grafana, Jenkins, or ArgoCD. Understanding how an IAM platform works at this level helps you make better access control decisions in any environment. The first step was creating an account at asgardeo.io and logging into the Asgardeo Console. The console is the central control panel for everything: applications, users, identity providers, login flows, and branding. It is clean and well structured, which makes it easy to navigate even on the first session. Asgardeo includes a built-in sample app called the Try It App. This is a sandbox that lets you test different login flows without needing to wire up your own frontend. I registered it as a new application in the console, which took about two minutes. Once registered, the Applications page lists it alongside My Account (the self-service portal). The app settings page shows all the tabs: General, User Attributes, Login Flow, and Advanced. The rest of the tasks all configure the login flow from here. Social login reduces friction for users and is a standard requirement in most modern applications. To add Google login, I registered an OAuth 2.0 application in the Google Cloud Console, obtained the Client ID and Client Secret, and then added Google as a Connection in Asgardeo. After that, I updated the login flow of the Try It App to include Google alongside the default username and password method. Once configured, the Classic Editor shows Google as an option in Step 1, and the live login page immediately shows the Sign In With Google button. Self-registration allows new users to create their own accounts without an administrator creating them manually. This is important for scaling user onboarding without adding operational overhead. In Asgardeo, enabling this is straightforward: navigate to Login and Registration > User Onboarding, and toggle Self Registration on. I also enabled account verification, which sends a confirmation email before the account is activated. With this on, the login page automatically shows a registration link. Password recovery is a basic but critical feature. Without it, every forgotten password becomes a support ticket. I enabled Email OTP-based password recovery in the Login and Registration settings. Once active, the login page shows a Forgot password link. Users enter their username, receive a one-time code by email, and can set a new password after verifying it. The entire flow is handled by Asgardeo with no extra code required. Asgardeo gives you full control over the look of the login page through a branding editor. I selected the Centered layout and set the primary color to #FF7300, which updates all action buttons, links, and highlights. The editor shows a live preview on the right as you make changes, so you can see exactly what the login page will look like before saving. For a real deployment, this is where you would add a company logo, set brand colors, and adjust typography so the login page feels like part of your product. A single-factor login, just a username and password, is not enough for anything that handles sensitive data. Multi-Factor Authentication adds a second layer that an attacker would need to break through even after obtaining a password. I updated the login flow in the Classic Editor to a two-step process: After this change, any user who logs in with a username and password gets prompted for a one-time code sent to their email before they are granted access. The Visual Editor gives a clear picture of how the two steps connect. This was the task I found most technically interesting. Adaptive authentication lets you write JavaScript logic that runs on every login attempt and controls the flow dynamically based on context. Instead of a fixed login experience for all users, you can apply different rules based on how they authenticated, what device they are using, or any other signal Asgardeo provides. My goal was specific: users who sign in with Google should skip the Email OTP step, because Google already performs its own identity verification. Users who log in with a username and password must always complete the second factor. Here is the script I implemented: The script runs after Step 1 completes. It checks whether the authenticated user came through a federated identity provider. If yes, the session is complete. If no, it calls executeStep(2) to trigger Email OTP. This is a simple example, but the same pattern scales to more sophisticated policies: enforcing MFA only for admin roles, requiring extra verification for logins from new locations, or applying stricter checks outside business hours. Note: The adaptive script editor is inside the Login Flow tab of the Try It App. Scroll down past the Classic Editor to find the Conditional Authentication section and paste the script there. I registered a new account using the self-registration form. The form collected email, password (validated against complexity rules on the spot), first name, last name, date of birth, mobile number, and country. A verification email was sent immediately after submitting. After confirming the email, I logged in with the new account credentials. After entering the correct username and password, the system immediately prompted for an Email OTP. After entering the code, login completed successfully. This confirmed Tasks 4 and 7 were working together correctly. I tested the forgot password flow: clicked the link on the login page, entered the username, received an OTP code by email, and set a new password. The screen on the right shows the initial prompt where the user enters their username and clicks Send Email OTP. The screen on the left shows the final Reset Password form after verifying the OTP. This was the real test of Task 8. I clicked Sign In With Google on the login page, selected my Google account from the account picker, and was logged in directly without any Email OTP prompt. The adaptive script correctly detected the Google identity provider in Step 1 and skipped the second factor entirely. The result is exactly the right balance: users who authenticate through a trusted external provider get a seamless experience, while standard credential logins always go through the stricter flow. Authentication is often the last thing teams think about and the first thing that gets exploited. Going through this assignment made a few things clearer. IAM platforms like Asgardeo handle an enormous amount of complexity that you should not be building yourself. Token lifecycle, OTP delivery, social login flows, MFA enforcement: all of this is solved infrastructure that just works out of the box. Adaptive authentication is genuinely powerful from an operational security standpoint. A policy like requiring MFA for all standard logins but skipping it for trusted external providers is exactly the kind of rule that prevents entire classes of incidents without annoying your users. SSO integration for internal tooling is also one of the highest-ROI security improvements a DevOps team can make. Once you understand how identity provider connections work in a platform like Asgardeo, you can apply the same pattern to Grafana, ArgoCD, Jenkins, and anything else that supports OIDC or SAML. If you are exploring Asgardeo for the first time, the Try It App is the right place to start. You can work through all of these features in an afternoon without setting up any infrastructure. Get started at asgardeo.io and the free tier is more than enough to go through everything in this post. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse