william_johnson

  Will Johnson is a Developer Advocate at Auth0. He loves teaching topics in a digestible way to empower more developers. He writes blog posts, records screencasts, and writes eBooks to help developers. He's also an instructor on <a target='_blank' rel='noopener noreferrer' href='https://egghead.io'><strong><b>egghead.io</b></strong></a>.


Developer Advocate

Will Johnson

Connect your Auth0-secured Model Context Protocol (MCP) server to ChatGPT. Learn how to enable Developer Mode, configure custom connectors, authorize connections with Auth0 Universal Login, and interacting with your API in chat.

OpenAI has announced a powerful new capability: [the ability to securely connect any Model Context Protocol (MCP) server directly through ChatGPT's interface](https://x.com/openaidevs/status/1965807401745207708?s=46&t=-1smoTARFb9vwko7N-kiqQ). This is fantastic news for developers, especially if you already have an MCP server secured by Auth0. This integration allows ChatGPT to perform both read and write actions, turning your AI assistant into a robust tool for managing your tasks.

In this post, we'll walk you through the complete process of connecting your Auth0 secured Todos API to ChatGPT, from enabling Developer Mode and configuring your connector to authorizing the connection and interacting with your API in a chat.

## Understanding ChatGPT Developer Mode and MCP

[ChatGPT Developer Mode](https://platform.openai.com/docs/guides/developer-mode) is a beta feature providing full Model Context Protocol (MCP) client support for all tools exposed by a connected MCP server. This enables ChatGPT to not only fetch data but also execute significant write operations by calling functions on your server.

> **A Crucial Note on Security**: This mode is powerful and intended for developers who understand how to safely configure and test connectors. Always be vigilant for prompt injections, carefully review all tool calls (especially write actions to prevent data destruction), and ensure you trust any MCP server you connect, as malicious ones could attempt to steal information.

## Prerequisites

To follow along, you'll need:
* A ChatGPT Pro or Plus account (Developer Mode is a beta feature).
* An existing Remote MCP server that you want ChatGPT to interact with.
* For detailed instructions on this setup, you can follow [our guide on how to secure and deploy remote MCP servers with Auth0 and Cloudflare](https://auth0.com/blog/secure-and-deploy-remote-mcp-servers-with-auth0-and-cloudflare/). 
* We'll assume your API is configured in Auth0 and enforcing Auth0-issued access tokens.

## Step 1: Enable Developer Mode in ChatGPT

First, we need to enable this beta feature within ChatGPT.

1. Open your ChatGPT interface and navigate to **Settings**.
2. Select the **Connectors** tab.
3. Click on **Advanced settings**.
4. Toggle on **Developer Mode**. This unlocks the options for creating custom connectors.

![](https://images.ctfassets.net/23aumh6u8s0i/3oVP3YLYUqARP0oR6DA4Iw/cae4dcf234c118a6ff789cc4f5c19050/Screenshot_2025-09-11_at_1.12.02_PM.png)

## Step 2: Create a Custom Connector

Once Developer Mode is enabled, you have the option to create custom connectors. This is where you'll point ChatGPT to your MCP server.

1. In the Connectors settings, click on **Create**.
2. Provide the information for your MCP server:
* **Name**: Give it a descriptive name, like "My Test MCP" or "Todos API".
* **Description (Optional)**: Add a brief description of what the API does.
* **Icon (Optional)**: Provide an icon for easy identification.
* **MCP server URL**: Enter the full URL of your Auth0-secured API.
3. Make sure Authentication is set to "OAuth." Auth0 will handle the authentication flow externally, so ChatGPT does not need to manage credentials directly.
4. Confirm that you trust this application by clicking the checkbox
5. Click **Create**.

![](https://images.ctfassets.net/23aumh6u8s0i/6y90YbyvzAZ5SRLw7dDizQ/ab5c34164b2a71df9a80b270b01444a3/Screenshot_2025-09-11_at_1.12.42_PM.png)

## Step 3: Authorize the Connection with Auth0
Now, you need to authorize ChatGPT to connect to your MCP server.

1. After clicking Create, ChatGPT will initiate the connection.
2. Because your server is secured by Auth0, you will be redirected to the Auth0 Universal Login page.
3. Log in with your user credentials and click **Allow Access**
4. After a successful login and consent, you will be redirected back to ChatGPT. Your remote MCP server is now securely connected!

![](https://images.ctfassets.net/23aumh6u8s0i/2D2dAR6HuCmZvYbTUX2squ/c5c16c757789def6f9d9417ff459aa0e/Screenshot_2025-09-11_at_1.10.14_PM.png)

## Step 4: Interact with Your Remote MCP Server in a Conversation

Let's see how you can now talk to your newly connected API.

Start a new chat in the main ChatGPT interface.Click the plus icon (+) in the composer and select **More**. Then choose **Developer mode**. This opens a new interface where you can select your custom data sources.Select your newly created connector (e.g., "My Test MCP") to add it as a source for this conversation. 

Now, you can ask it to perform an action using your API. For example, type the prompt: *"list my todos"*. ChatGPT will recognize that this requires an action from your MCP server and propose a "tool call". It will show you the details of the call it intends to make. 

Click **Confirm** to allow ChatGPT to send the request to your API.

![](https://images.ctfassets.net/23aumh6u8s0i/ir0DNLQQDCYzi9mj3u7aY/cd1d3e46f7504d01284175c943bc5ab0/Screenshot_2025-09-11_at_1.15.42_PM.png)

After you confirm, ChatGPT will display the results of the query, showing you the information retrieved directly from your Auth0-secured MCP server. You have successfully extended ChatGPT's capabilities to interact with your own secure services.

![](https://images.ctfassets.net/23aumh6u8s0i/7cZvI9seZtermqPUvkohVe/8c4e207aa30a7ba1e6d9530a9bcd3bf5/Screenshot_2025-09-11_at_1.31.36â__PM.png)

## Recep and further reading 
You've successfully added your Auth0 secured remote MCP server with ChatGPT, giving access to resources right inside of ChatGPT. This process involved:

1. **Enabling Developer Mode** in ChatGPT settings.
2. **Creating a Custom Connector** by providing your remote MCP server URL with OAuth authentication.
3. **Authorizing the Connection** through the Auth0 Universal Login page.
4. **Interacting with your API** in the chat window by selecting your custom connector and confirming tool calls.

Check out some other MCP Content we have on the Auth0 Blog

* [How to Configure the Auth0 MCP Server in VS Code for AI Assistant Integration](https://auth0.com/blog/auth0-mcp-server-in-vscode/)
* [How to Build a Python MCP Server to Consult a Knowledge Base](https://auth0.com/blog/build-python-mcp-server-for-blog-search/)
* [Why Can't I Just Use an API? Because Your AI Agent Needs MCP](https://auth0.com/blog/mcp-vs-api/)

Integrate Your Auth0 Secured Remote MCP Server in ChatGPT Developer Mode

Learn why native Google Sign-In creates a faster, more trusted login for your Android app. See how Auth0 and Credential Manager deliver a seamless UX.

When you're building a mobile app, login flow is one of the first places users decide if your app feels polished or clunky. For Android users, nothing feels more natural than using the Google account already on their phone to log in. That’s what native Google Sign-In offers: no redirects, no browser tabs, just a fast, familiar experience.
Auth0 supports this native flow, allowing you to authenticate users with their Google account and still benefit from all of Auth0’s token handling, identity verification, and security features. The end result is a login experience users trust, while keeping your backend logic and architecture unchanged.

## Why native Google Sign-In is worth it

If you’re using [Auth0 Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) already, you might be wondering if native Google Sign-In is worth the extra effort. Spoiler alert: **It is!** Here are some reason why developers who care about speed, UX, and brand trust should consider going native on Android.

### Faster login times

Native sign-in eliminates the browser round-trip, a process that can take several seconds due to network latency, page loads, and redirects. By using the on-device account directly, the login time is reduced to the milliseconds it takes for the native UI to appear, often resulting in a 70-80% faster login experience.

### Future-proofing with Android Credential Manager

Beyond the immediate UX gains, choosing the native flow is a strategic decision that aligns your app with the future of the Android platform. Google not only recommends this approach but has built its modern identity tools around it.

This flow is designed to work directly with [Credential Manager](https://developers.google.com/identity/android-credential-manager), which is Android's unified home for all sign-in methods, including passwords, passkeys, and federated logins like Google. By adopting this modern API, your app can securely retrieve saved credentials from the Google Password Manager, enabling the same seamless, one-tap sign-in for returning users that was previously offered by Smart Lock.

For developers, this means you're building on a future-proof foundation. As Google evolves its identity and authentication features, your app will be positioned to seamlessly integrate them, reducing long-term maintenance and keeping your app feeling modern and integrated into the Android ecosystem.

### A seamless UX that builds trust

Redirecting users to a browser breaks the trusted context of your application. That brief journey to an external web view introduces uncertainty: "Is this the real Google login page, or a phishing attempt?" Native sign-in reinforces the principle of a secure boundary. The login prompt is presented by the Android OS itself, a universally trusted party, that assures the user that their credentials are being handled securely within the device's native ecosystem.

> Why trust matters: For apps that handle sensitive data, such as finance or healthcare, building trust at every step is essential. Redirecting users to an external web view can break that trust by introducing unfamiliar UI or delays. In an Auth0 UX research study, a developer from the financial sector shared that they couldn’t afford any hiccups in the user flow. Because their app required users to enter sensitive financial data, building complete trust was a priority, and web redirects didn’t provide the same level of reassurance as a native experience.

Native sign-in reinforces credibility by keeping the flow consistent, fast, and secure, just what high-trust industries demand.

And best of all, Auth0 lets you implement this while keeping your existing identity setup.

## Under the hood: How native login works

So, how does this flow achieve both a seamless user experience and security? It relies on a multi-step handshake between your app, the Android OS, and Auth0.

Consider the following diagram:

![](https://images.ctfassets.net/23aumh6u8s0i/2fTJqdIeKLQ433qRHT4lua/8f416489dc0b87eaa9dd97c821aba70b/Untitled_diagram___Mermaid_Chart-2025-07-16-193722.png)

Following the numbered arrows, here is a breakdown of the flow in the diagram:

1. **Request Credential:** Your Android app initiates the login by asking the Android OS's
Credential Manager for a Google credential, providing a unique nonce for security.

2. **User Interaction:** The Credential Manager displays the familiar, native Google account picker to the user. 

3. **Account Selection:** The user selects their account.

4. **Google Issues Token:** The Credential Manager communicates with Google's services in the background, which issue a secure, signed ID Token.

5. **Token Received by Credential Manager:** The Credential Manager receives the ID Token issued by Google.

6. **Token Received by App:** The ID Token is passed back to your Android app.

7. **Token Exchange with Auth0:** Your app sends this Google ID Token to Auth0 along with the nonce generated at the request time.

8. **Validation:** Auth0 validates the token's signature using Google's public keys and verifies the nonce to prevent replay attacks.

9. **Auth0 Credentials Issued:** Upon successful validation, Auth0 returns its own set of credentials (an Access Token and ID Token) to your app.

10. **Login Complete!** Your app now has a secure session managed by Auth0.

Two security concepts make this handshake work:

* **The ID Token as Proof:** When a user consents, the Android OS doesn't just return a username. It asks Google to generate a signed ID Token (a JSON Web Token, or JWT). This token is a verifiable piece of cryptographic proof that contains the user's identity, who it was issued to (your app), and most importantly, a nonce.

* **The nonce and the Secure Exchange:** The nonce (number used once) is a random, unique string your app generates at the start of each login attempt. It gets embedded inside the signed ID Token from Google. When your app sends this token to Auth0, Auth0 performs a critical check: it verifies that the nonce inside the token matches the one it expected for that specific transaction. This instantly defeats replay attacks, where an attacker might try to reuse an old or stolen token. Once validated, Auth0 exchanges the Google ID Token for a set of its own credentials.

## How the concepts look in code

Now that you understand the "why," let's walk through how the pieces connect in practice. The following code snippets, also available in a [GitHub Gist](https://gist.github.com/willjohnsonio/e2ecd4cec1fbcebc933f796fe010a347), illustrate the core steps of the flow in an Android app.

**Step 1: Requesting credentials from Google**

First, use `GetGoogleIdOption` to configure your request. This is where you’ll provide two crucial pieces of security information:

* `setServerClientId(...)`: This must be the Client ID from your Web Application credentials in the Google Cloud Console. This tells Google that you intend for the resulting ID Token to be used by a backend server (in this case, Auth0).

* `setNonce(...)`: Provide a unique, random string for every login

```kotlin
val randomNonce = UUID.randomUUID().toString()

val googleIdOption = GetGoogleIdOption.Builder()
    .setFilterByAuthorizedAccounts(false)
    .setServerClientId(getString(R.string.com_google_client_id))
    .setNonce(randomNonce)
    .build()

val request = GetCredentialRequest.Builder()
    .addCredentialOption(googleIdOption)
    .build()
```

**Step 2: Handling a unified result**

A key concept to understand is that Credential Manager is a unified API. It’s built to handle not just "Sign in with Google," but also saved passwords and modern passkeys, all through the same entry point. Because of this, your code must check what type of credential the user actually selected.

The standard way to do this is with a `when` statement. You inspect the `result` from the `getCredential()` call to confirm it's the specific type you're expecting for this flow: `TYPE_GOOGLE_ID_TOKEN_CREDENTIAL`. This check ensures your app responds correctly and securely.

Once you've verified the type, you can then "unbox" the data to get the Google ID Token.

```kotlin
try {
    val credMan = CredentialManager.create(this)
    val result = credMan.getCredential(
        context = this,
        request = request
    )

    val creds = result.credential
    when (creds) {
        is CustomCredential -> {
            if (creds.type == GoogleIdTokenCredential.TYPE_GOOGLE_ID_TOKEN_CREDENTIAL) {
                val googleCredentials = GoogleIdTokenCredential.createFrom(creds.data)
                // Rest of the code
            }
        }
        // Handle other credential types like passkeys or passwords if needed
        else -> {
            // Handle other cases or errors
        }
    }
} catch (e: GetCredentialException) {
    // Handle exceptions from getCredential(), such as the user canceling the flow
}
```

**Step 3: Exchanging the token with Auth0**

Finally, you send the `idToken` from Google to Auth0 using the `loginWithNativeSocialToken` method. The `tokenType` parameter is important, because it tells Auth0 which validation strategy to use. In this case, it will use Google's public keys to verify the token's signature.

```kotlin
auth0Client.loginWithNativeSocialToken(
    googleCredential.idToken,
    "http://auth0.com/oauth/token-type/google-id-token"
)
.setScope("openid profile email")
.start(object : Callback<Credentials, AuthenticationException> {
    override fun onSuccess(auth0Creds: Credentials) {
        // Store credentials and update UI
    }

    override fun onFailure(error: AuthenticationException) {
        // Show error message
    }
})
```

## Upgrade your Android users sign-in experience with Auth0

If your Android app already uses Auth0, native Google Sign-In is one of the easiest upgrades you can make for a better user experience. It’s fast, secure, and better aligned with Android platform expectations.

Native Google Sign-In gives you a more trusted, smoother login experience that fits naturally into the Android ecosystem, all without requiring backend changes or major migrations.

To learn more, check out the Auth0 docs on [Native Google Sign-In](https://auth0.com/docs/authenticate/identity-providers/social-identity-providers/google-native).

Why Native Google Sign-In Makes Android Apps Feel Right

NickApostolu

Nick Apostolu is a Staff Product Marketing Manager at Okta, empowering healthcare organizations to harness IAM solutions to meet critical business goals like optimizing the patient experience, strengthening their security posture, increasing clinician efficiencies, and cutting costs. Prior to joining Okta, Nick has spent the majority of his career at healthcare technology organizations as a product marketer with primary focus areas of revenue cycle management, payments, and population health analytics.

Staff Product Marketing Manager, Healthcare

Nick Apostolu

Discover how federated identity management solves the multi-org challenge, unifies user experiences, and boosts efficiency for complex enterprises.

Beyond the Single Login: How Federation Powers Multi-Org Success

andrea-chiarelli

I have over 20 years of experience as a software engineer and technical author. Throughout my career, I've used several programming languages and technologies for the projects I was involved in, ranging from C# to JavaScript, ASP.NET to Node.js, Angular to React, SOAP to REST APIs, etc.

In the last few years, I've been focusing on simplifying the developer experience with Identity and related topics, especially in the .NET ecosystem.

Principal Developer Advocate

Andrea Chiarelli

Learn how to enable your customers to customize the login experience of your B2B SaaS application and integrate it into their systems by accessing your APIs.

Throughout this series, we've journeyed through [the foundational aspects of B2B identity](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/), including multi-tenancy and onboarding, then delved into [granular access control with RBAC, ABAC, and ReBAC](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/), and most recently tackled [the critical demands of enterprise integration and advanced security](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/). Your Business-to-Business (B2B) Software-as-a-Service (SaaS) application is now robust, secure, and ready for demanding clients.

However, the ultimate success of a B2B application often hinges on its adaptability and seamless integration into a customer's environment. This means more than just functionality; it means brand consistency and programmatic access.

In this concluding article, we will explore the essential aspects of customization and extensibility, focusing on how to tailor the user experience and secure your backend APIs for machine-to-machine communication, ensuring your application is truly integrated and personalized for every customer.

## Branding and User Experience Customization

Your B2B customers will often expect a seamless brand experience, even on the login page. They want their users to feel like they are interacting directly with their application, not an external provider. This is also reflected in your application’s login pages: **How can I customize the login pages to match my customers' corporate identities?**

To be honest, in my previous experience in building a B2B SaaS application, we had a couple requests of this type. At that time, we decided to implement an additional set of login and reset password pages. Basically, they were customized versions of our default login page. As a result, we had to maintain more code and keep in sync with any updates we were going to apply to the default pages. It worked with some additional maintenance, but only because we had very few such requests. As a developer, you know that the more code you have, the more trouble you may get.

[Auth0's Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) is designed for extensive customization, allowing you to maintain a consistent brand experience across all your customer organizations. Customizing Auth0 Universal Login for individual Organizations is a powerful feature for B2B SaaS applications, allowing you to provide a truly branded experience for each of your customers. You can customize it at different levels: 

* With a **no-code approach**, which allows you to change the logo and colors of the login page.  
* With an **advanced approach** by customizing the Universal Login page template with Liquid.  
* With more powerful control by using the **Advanced Customizations** for Universal Login feature, which gives you control over every pixel of your Universal Login experience.

But that’s not all. Auth0 also allows you to customize the emails that users receive from the platform very easily.

> Read the following documents to learn more about customizing the login experience for your customers:
> 
> * [Customize Universal Login](https://auth0.com/docs/customize/login-pages/universal-login)  
> * [Advanced Customization for Universal Login](https://auth0.com/docs/customize/login-pages/advanced-customizations)  
> * [Customize Prompts and Email Templates for Organizations](https://auth0.com/docs/manage-users/organizations/create-first-organization#customize-prompts-and-email-templates)

## API Security for Your SaaS Backend

In the context of customization, it is likely that some customers will ask you to access your application's APIs to connect them with their systems, for example, to exchange data automatically. The challenge now becomes: **How can I protect my backend API so that my customer’s applications can only access their data securely?**

Auth0 enables you to implement this feature by providing Machine-to-Machine (M2M) Access for Organizations. To determine the Organization your API is scoped to, you will find an `org_id` claim in the access token sent by the customer’s application.

> Here is more information about securing your API in the context of Organizations:
> 
> * [Machine-to-Machine (M2M) Access for Organizations](https://auth0.com/docs/manage-users/organizations/organizations-for-m2m-applications)  
> * [Work with Tokens and Organizations](https://auth0.com/docs/manage-users/organizations/using-tokens)

## Real-time User Lifecycle Management with Event Streams

Beyond offering your customers direct API access and UI customization, your B2B SaaS application may need to react to changes in user identity in real time. Imagine needing to synchronize user data with your CRM, trigger welcome emails based on signup events, or update internal billing systems when a user's status changes. Relying on polling APIs or manual data exports is inefficient and can lead to inconsistencies.

The challenge here is: **How can I reliably and efficiently propagate user lifecycle events from Auth0 to my internal systems or third-party applications?**

[Auth0 Event Streams](https://auth0.com/docs/customize/events) provide a solution to this. Event Streams allow you to subscribe to a real-time feed of events generated by Auth0, such as:

* User creation  
* User updates (e.g., profile changes)  
* User deletions  
* Password changes  
* Login successes and failures

These events are delivered to a destination of your choice, such as Amazon EventBridge or an HTTP endpoint. This enables you to build event-driven architectures, ensuring that your other services are always up-to-date with the latest identity information without complex polling logic. By leveraging Event Streams, you can automate critical workflows and maintain data consistency across your B2B SaaS ecosystem.

> Learn more about Auth0 Event Streams:
> 
> * [Auth0 Event Streams](https://auth0.com/docs/customize/events)  
> * [Discover User Lifecycle Changes via Event Streams – Now in Early Access](https://auth0.com/blog/user-lifecycle-changes-via-event-streams-in-early-access/)

# Conclusion

Our journey through the identity landscape of B2B SaaS has traversed from the fundamental need for user authentication to the sophisticated demands of enterprise integration and bespoke logic. What might initially seem like a peripheral concern — simply letting users log in — quickly reveals itself as the bedrock upon which the security, scalability, and ultimate success of your B2B application are built.

We started by understanding that **B2B identity is fundamentally different** from Business-to-Customer (B2C), centered around organizations rather than just individual users. We then progressed through key developmental phases: from [laying the foundation with multi-tenancy support](https://auth0.com/blog/b2b-saas-identity-challenges-the-foundations/) to exploring [different approaches for granular access control](https://auth0.com/blog/b2b-saas-identity-challenges-granular-access-control/); from tackling the non-negotiable [integration needs for enterprise customers](https://auth0.com/blog/b2b-saas-identity-challenges-enterprise-integration-and-security/) to facing the customization and extensibility requirements.

By embracing a robust identity solution from the outset, you’re not just solving a technical problem; you're laying a strategic foundation for your B2B SaaS application to thrive in a competitive and security-conscious market. Your focus can remain on delivering exceptional business value, confident that your users and their data are in safe hands.

I hope this series has provided valuable insights and practical solutions for navigating the complex world of identity in B2B SaaS.

Ready to secure your B2B SaaS and accelerate your development with a trusted identity partner? Explore [Auth0's comprehensive offerings](https://auth0.com/b2b-saas) and see how they can transform your approach to identity and access management.



B2B SaaS Identity Challenges: Customization and Extensibility

ana-cidre

Ana Cidre is a passionate advocate for the developer community and leads the Developer Advocacy team at Auth0. She's committed to fostering a more inclusive and diverse tech world, drawing on her technical background and strategic vision to improve developer experiences and build meaningful connections.

<br>

As the founder of GalsTech, an initiative supporting women in tech in Galicia, and through her active efforts to create welcoming spaces for underrepresented groups, Ana's dedication to diversity and inclusion extends beyond her daily work.

<br>

Ana has a proven track record of building global Developer Relations teams, cultivating active developer communities, and crafting impactful educational content. She maintains a strong connection to the community through speaking engagements and direct interaction with developers.

Sr Manager, Developer Advocacy

Ana Cidre

Auth0 May 2025 updates: async auth (CIBA), CLI tools, real-time event streams, and customizable Universal Login. Enhance security, UX, and integrations.

May brought a wave of powerful new capabilities for you: async authentication flows with CIBA, fine-grained M2M quotas for secure API usage, expanded event streaming for automation, and even more control over the Universal Login experience, including WebAuthn and biometrics.

If you’re building with Auth0, this month’s releases give you more control over UX, security, and system integrations with less friction.

## Let’s Dig In

### Client-Initiated Backchannel Authentication (CIBA) – Now GA

![Client-Initiated Backchannel Authentication (CIBA) – Now GA](https://images.ctfassets.net/23aumh6u8s0i/74Extty3wWiKZ9ZDNwoHUd/d20ed90066e9535cf980ab1399b71485/CIBA.png)

The **CIBA flow** is now Generally Available, and it's a game changer for devs building across devices, services, and roles.

It enables **asynchronous authentication** where:

* One device **initiates** the request (e.g., a smart TV, AI agent, CLI tool)
* Another device **authenticates** the user (typically a mobile app with Guardian SDK)

**Highlights:**

* Works great for headless UIs, customer service flows, or AI agents needing human approval
* Built on **Rich Authorization Requests** (RFC 9396)
* Auth can happen off-screen, out-of-band, or in-context

> Explore CIBA in the [docs](https://auth0.com/docs/get-started/authentication-and-authorization-flow/client-initiated-backchannel-authentication-flow/user-authentication-with-ciba).

### Auth0 CLI: More UX control, better testing, new powers

The latest CLI update gives developers even more hands-on control over login, org testing, and tenant config.

New capabilities:

* Customize Universal Login from the CLI
* Block/unblock users programmatically
* Use `test login` with Organizations
* Better logs + user management commands
* Bug fixes + smoother workflows

> Check the [CLI reference](https://auth0.github.io/auth0-cli/).

### Event Streams for extensibility – now in Early Access

Already loved for user lifecycle events, **Event Streams** now support **Extensibility Events**.

This means you can:

* Subscribe to changes in users and organizations
* Route real-time events to Webhooks or EventBridge
* Build automation and observability into your dev workflow

Use this to sync downstream systems, trigger CI/CD pipelines, or log important changes without polling the Management API.

> Set up your [stream](https://auth0.com/docs/customize/events/create-an-event-stream).

### Universal Login: WebAuthn, Biometrics, and Logout – now customizable

![Universal Login: WebAuthn, Biometrics, and Logout – now customizable](https://images.ctfassets.net/23aumh6u8s0i/5RJDBKzJH664XABPw5VAf2/a534dc8277dbce2bae3bd67f3db5911d/Universal_Login.png)

The [Advanced Customizations for Universal Login (ACUL)](https://auth0.com/docs/customize/login-pages/advanced-customizations) SDK just leveled up.

You can now build client-rendered, pixel-perfect versions of:

* **MFA with WebAuthn** (roaming + platform)
* **Biometric flows**
* **Reset password screens**
* **Logout states** (completed, error, aborted)

### Tooling support:

* ACUL SDK
* Auth0 CLI
* Deploy CLI
* Terraform Provider

No more default templates - your login experience, your UI, your rules.

### More cool features we have shipped to improve your experience: 

#### Universal Login language selector for end users

Tired of relying on browser headers or `ui_locales`? You can now **let users choose their preferred language** directly on Universal Login pages using Custom Prompts.

#### Fine-Grained M2M Token Quotas (now in Early Access) 

Allows you to set precise hourly and daily limits on machine-to-machine token issuance at the app or organization level. This helps prevent API abuse from misconfigured clients, returns automatic 429 responses when limits are hit, and provides full visibility through logs and response headers. No external rate limiting or token caching hacks required.

#### Native Sign-in with Google for Android

If you’re building native Android apps, you can now use the **Android Credential Manager’s Sign in with Google** to let users authenticate seamlessly using their existing Google sessions - no passwords, no extra prompts.

## Community and Events

### Where we were in May

May took us around the world—from live webinars to some of the most exciting developer and API conferences.

* **Qiita Webinar with Twilio** &mdash; Daizen Ikehara shared strategies for building **scalable and secure SaaS apps** tailored for the Japanese developer ecosystem.
* **Infobip Shift** – Carla Urrea spoke about “Securing AI: A Journey Through Access Control Systems.”
![Infobip Shift](https://images.ctfassets.net/23aumh6u8s0i/5vokh8jDIdVDFU3eWwOAnc/f6758558c0803cbe33a56b46c1e0eebf/events01.jpg)
* **API Days New York** – Ramona Schwering talked about AI and security
* **Dublin Tech Summit** – Deepu Sasidharan talked about how OAuth and OpenFGA Can Keep Your AI Agents from Going Rogue!
![Dublin Tech Summit](https://images.ctfassets.net/23aumh6u8s0i/2aQY44SfC8hnCSQ5WADHhu/df2e04f745af6552b1b7df3476df846e/events02.jpg)

### Where we’ll be in June

June is shaping up to be a big month for developer events, and we’re showing up in full force across frontend, AI, open source, and cloud communities. If you’re attending any of these, come say hi, catch a talk, or grab some Auth0 swag!

**dev_day(25)** (June 18th) - dev_day(25): Auth for Agents is a one-day, free, virtual crash course on auth for AI agents and humans with Auth0. [RSVP](https://developerday.com/rsvp) today to join us on June 18th.

* **Frontend Nation 2025** (June 3rd) – Ramona Schwering will share tips on building secure, user-friendly frontends.
* **AI Engineering World's Fair** (June 3rd) – Exploring the future of AI-powered software and secure identity in agent workflows.
* **AWS Summit Hamburg** (June 5th) – Juan Cruz Martinez joins to discuss secure multi-tenant patterns for AWS builders.
* **RenderATL** (June 11th) – Ramona Schwering and Jessica Quick will be alongside Netlify at the booth, while Shawn Meyer will be on a panel on AI.
* **React Summit** (June 13th) - Ramona returns to the stage with a developer-first approach to modern identity in React apps.
* **VLCTechFest** (June 14th) - Carla Urrea joins the dev community in Valencia to connect on open source and identity.
* **Open Source Summit North America** (June 23rd) - Carla shares insights on securing community-led software.
* **AWS Summit Japan** (June 25th) - Daizen Ikehara will present best practices for large-scale identity in the public cloud.
* **Vercel Ship** (June 25th) - Juan Cruz Martinez will be on-site with a spotlight on edge-first auth patterns for AI apps.

Planning to attend? Reach out! We’d love to meet you and hear what you’re building.

Expect talks, demos, and plenty of real-world tips on building secure, AI-aware, and scalable identity experiences.

That’s it for May! We’ll be back next month with more dev-first updates.

Until then:

Stay secure. <br>
Keep shipping. <br>
We’re here if you need us. <br>

May 2025 in Auth0: Async Auth, Real-Time Streams, and Custom Everything

Linda Gong

Linda Gong is a Product Marketing Manager for Orchestration at Okta, where she leads go-to-market strategy for Okta Workflows and Auth0 Extensibility. With a background in demand generations and marketing analytics, she brings a data-driven mindset to messaging, product launches, and driving adoption. When she’s not crafting product narratives, you’ll likely find her hunting down the best local coffee shops or planning her next travel adventure.

Product Marketing Manager

Auth0 + Sift integration delivers real-time, risk-based fraud detection and prevention while enabling frictionless logins for legitimate users.

Nearly [$13 billion](https://javelinstrategy.com/research/2024-identity-fraud-study-resolving-shattered-identity-crisis) — that’s how much account takeover (ATO) fraud cost businesses in 2023 alone. This isn’t just another alarming stat — it’s a wake-up call for any organization managing user accounts. Industries like e-commerce and financial services are feeling the heat, with ATO attack rates spiking [36%](https://sift.com/index-reports-account-takeover-fraud-q3-2024) and [10%](https://sift.com/index-reports-account-takeover-fraud-q3-2024) year-over-year, respectively.

The methods behind these attacks aren’t new: stolen credentials from data breaches, phishing attacks, and malware are still the go-to tools for fraudsters. What is new? The scale, sophistication, and speed of these attacks. And traditional defenses—CAPTCHA, static rules, even MFA—aren’t enough on their own.

### What you need: Real-time, AI-driven fraud defense

That’s where Auth0 + Sift comes in. Together, they deliver real-time, risk-based fraud detection and authentication at scale. With the pre-built integration, businesses can achieve robust ATO defenses quickly and with minimal engineering lift. 

With the Auth0 extensible identity platform and Sift’s AI-powered risk engine, you can automatically score risk, trigger adaptive MFA, and block bad actors—without slowing down your trusted users.

![Auth0 + Sift integration](https://images.ctfassets.net/23aumh6u8s0i/4E3Z7xaIl3d7lFbAY1qJWH/265b3594668967191449fad982a03f06/Screenshot_2025-04-28_at_6.03.34_PM.png)

### Check out the solution brief to learn how to stay ahead of account takeover attacks

Download [Auth0 + Sift integration solution brief](https://cdn.auth0.com/blog/blog/auth0sift-solution-brief.pdf) to discover:

* Why real-time, AI-powered risk assessment is essential to stop ATO fraud
* How the Auth0 + Sift integration works
* A real-world example from a global e-commerce platform
* Key outcomes: reduced fraud losses, enhanced user experiences, and increased operational efficiency



Account Takeover Attacks Are Surging — Stop Them With AI-Powered Fraud Defense

Aliyah Winfrey

I'm Aliyah Winfrey, a staff design researcher who’s passionate about creating clarity and alignment in complex research spaces. I thrive on asking the right questions and uncovering insights that drive meaningful design. Outside work, I tend to my garden, experiment with new baking recipes, or get lost in a classic PS2 game.

Staff Design Researcher

Brandon Simons

Brandon Simons is a Principal Product Manager at Auth0, where he has spent over three years dedicated to empowering customers to build great login experiences. His focus is on providing the right balance between ease of development and maintenance, while ensuring a delightful end user journey. Prior to his role at Auth0, Brandon spent over a decade working in SaaS at companies large and small.

Principal Product Manager

The benefits of leveraging social connections for your customers

Social Login has become a login method across [numerous regions, ages, and community types](https://auth0.com/blog/digital-identity-what-users-think-about-devices-and-logins/). Globally, we are connected through social media, and leveraging social login allows us to fortify those connections through a seamless and secure login. However, many everyday people don’t understand [how social login or social connections work](https://auth0.com/blog/analysis-of-social-connection-data/) or, more importantly, if [social login is a safe way](https://auth0.com/blog/social-login-on-the-rise/) to log in or sign up. 

Social login uses existing social media accounts, such as Google, Facebook, X (Formerly Twitter), Apple, and Microsoft, to sign in or go up for websites. It reduces the cognitive load of users remembering another username and password or, worse… _reusing a password_ 😱 over 70% of general users do. Over thousands of our customers have integrated Social Login in their authentication flow. Social login offers the following.

1. Frictionless and rapid method for users to sign up/log in via a 1-click solution
2. Implementing social login significantly increases the conversion rate.<sup><a href="https://auth0.com/blog/how-to-use-social-login-to-drive-your-apps-growth/#Increase-Your-Sign-Up-Conversion-Rate-by-20-">1 </a></sup><sup><a href="https://www.marketone.com/articles/maximizing-conversion-rates-with-social-sign-in">2</a></sup>
3. Security of social login 

However, internal research of general population users cited the sentiment that social login is the most vulnerable identifier to cyberattacks.

![Social login](https://images.ctfassets.net/23aumh6u8s0i/13wdcxqs5xSsqyzL1bkQjx/2dad6f825cb64537ce2ae1dd1d4884c5/Social_Login.png)

Given this sentiment, let’s break down three common myths about Social Login among general users and share some key points to keep in mind when using it in your applications.

## The Myths of Social Login

> **Myth #1**: Logging in via my social account (Facebook, Google, or Microsoft)  gives away the data in my social account.

Social account hacking is a huge and serious concern for everyday users. However, many social login services such as Google, Facebook, Apple, and Microsoft do not grant full access to your account and share only what’s necessary, such as name and email. Social Login providers share limited information with the application or website users are logging in to. Social login minimizes the data you store when signing up for accounts. The less data you store, _the better_.

This means they are not sharing your data on your social login account. Social login only grants authentication rights to create or log into an account. Additionally, many social login providers allow users to review, control, and revoke access to their account settings, meaning users must grant permission to access _any_ account data. Social login does not give the application or service users a sign-up for access to data such as private messages, browsing history, or other sensitive information.

> **Myth #2**: Social login is less secure than a password.*

Social login is often more secure than using a password for a few reasons. Traditional login methods, such as passwords, are prone to reuse and have general weaknesses, such as hackers guessing simple passwords. Social login reduces the risk by offering a passwordless way to authenticate. Moreover, users' risk of credential theft and phishing is diminished, given they are not creating and storing credentials to log in to third-party sites and services. Social Login often provides built-in Multi-Factor Authentication (MFA) as an added layer of security in comparison to relying on a password, which may or may not offer MFA.

Social login utilizes big companies like Google, Microsoft, and Apple's investment in keeping users’ accounts safe with a team of security experts working 24/7. These companies monitor accounts for unusual and suspicious activity, unauthorized access, and hackers. \

> **Myth #3**: Social Login isn’t safe cause it’s too easy.*

It’s really that simple. Ease of access ≠ lacks security. Social Login simplifies authenticating users as who they say they are while leveraging leading security measures. In other words, it’s simple authentication that does not sacrifice security. Remembering a password is more challenging and less secure. Weak or reused passwords pose a greater risk to personal data and security.

## Let’s Enable Our Users and Build Trust

Building trust with users is about more than just convenience. It requires a strong commitment to security, clear communication, and giving users the tools to protect themselves. Social login makes signing in easier while keeping accounts secure, but users should take extra steps to stay safe. Enabling MFA, reviewing permissions in Google, Microsoft, or Apple account centers, and staying aware of account activity all help strengthen security. When an organization provides these options and offerings, such as Auth0, allow for seamless integration, users take advantage of them, and online interactions become both safer and simpler.

Ready to rethink social login? Start implementing it in your apps, and learn more [here](https://auth0.com/learn/social-login)! Or [review some of our social login Labs](https://developer.auth0.com/resources/labs?topic=authentication)”

Demystifying Social Login

Exploring the evolving tech/identifier trends, needs, and behaviors of a global audience

As an advocate for developers and a company that trusts the developer community, we are open-sourcing this survey data to foster dialogue, innovation, and shared learning. By making these insights publicly available, we invite researchers, developers, and CIAM leaders to analyze and build upon our findings. Understanding global digital identity trends requires diverse perspectives, and an open-source approach allows for an informed and equitable discussion. 

Digital technologies continue to change human interactions, shaping global attitudes toward identity, security, and new technological innovations in similar and different ways. Our latest End-User Device & Login Sentiment survey highlights key trends in digital identity preferences, authentication methods, and security concerns. This survey and high-level takeaways contribute to the broader discourse of technology, CIAM, and an evolving general population market. Please find details on the purpose, audience, and collection below:

## Purpose

Understand the general population of global users' evolving technology needs and behaviors to identify key trends and shifts. The following Key topics were covered: 

**Device/OS usage**

* Personal vs. Work device usage 
* Device registration preference
* Work application usage

**Attitude towards technology**

* Overall tech familiarity 
* Hardware update motives
* Frequency of technology updates

**Identifier preference**

* Identifier familiarity 
* Identifier registration preference
* Perceived vulnerability and convenience 

**Password management**

* Reuse & Change Password
* Compromised PII
* Fraud Check

![Key Topics](https://images.ctfassets.net/23aumh6u8s0i/34N68QuL8Q9JZBT8ql8wXB/218ff72b8716be2887562adb892c3e28/key_topics.png)

### Research Questions

1. Understand current technology devices and usage patterns 
2. Identifying emerging trends in end-user preference 
3. Discover unmet needs and pain points to capitalize on new opportunities, driving innovation and strategic growth

### Target Audience

Partnered with Qualtrics for a 33-question survey in the following regions/countries: EMEA (France & United Kingdom), NAMR (United States & Canada), LATAM (Mexico & Brazil), and India. 

### Sample

**N=1049**

* Age
    * Age 18-23: 19%
    * Age 24-30 19%
    * Age 35-54: 32%
    * Age 55+: 30%
* Region
    * NAMR 25%
    * EMEA 25%
    * LATAM 25%
    * APAC 25%
* Gender
    * Male:48%
    * Female: 52%
* Community Type
    * 1/3 Rural
    * 1/3 Suburban
    * 1/3 Urban
* Household Income
    * Less than $25,000- 5%
    * $25,001 - $50,000- 10%
    * $50,001 - $75,000- 20%
    * $75,001 - $100,000- 30%
    * $100,001 - $150,000- 20%
    * $150,001 - $200,000- 10%
    * More than $200,000- 5%

### Data Integrity 

No personally identifying information (PII) was collected. All responses shorter than 3 minutes (180 seconds) were removed. The median completion time was 6.08 minutes. Participants were compensated for completing the survey. 

Samplings across regions are representative of age and gender distributions. For example, given the larger youth population, more youth aged 18 to 30 were sampled in India. Given the country's demographics, ages ranging from 45 to 59+ were skewed towards EMEA and NAMR. 

Additionally, LATAM skewed predominantly toward the urban community type, EMEA represented much of the rural community type, and NAMR led heavily toward the Suburban community type.

### Regression analysis

![Regression analysis](https://images.ctfassets.net/23aumh6u8s0i/2cF18Iz0eEWlprYHPlHlFR/f21d36a8cb21cabedd6100f1037f7aba/Regression_analysis.png)
_Logistic Regression on survey data was completed to gauge if any response options forecast an individual's Willingness to Try New Identifiers. No substantial evidence indicates these factors are significant predictors._

<br>
Six low-level predictors for Willingness to Try New Identifiers were identified. These include the following:

1. Attitude towards New Tech
2. Familiarity with Identifiers other than Email and Username
3. How often do individuals update their devices
4. Age
5. Apple-Only OS Owners
6. APAC/India region 

Data was collected in October of 2024. Data is accessible via a[ CSV. file](https://cdn.auth0.com/blog/blog/End-User-Sentiments-Survey.csv).

#### Citation

1 End-User Device and Login Sentiment, Auth0, 2024. [Link](https://auth0.com/blog/digital-identity-what-users-think-about-devices-and-logins/)

## Insights

### Top 10 Learnings 

1. Android Phone and Windows OS more widely adopted across diverse groups: <br>
 - Adoption more prevalent in LATAM and APAC
 - Android users tend to be lower to middle-household income 
![Android, Windows OS lead in adoption](https://images.ctfassets.net/23aumh6u8s0i/1cz14tdcdDmqEZI5ZBgD9M/15021e7a00fe7d4967d9255f16f99b7d/Screenshot_2025-03-21_at_12.39.11_PM.png)
2. Younger demographics and higher income are more likely to use Apple OS <br>
 - Apple OS more pronounced in EMEA and NAMR
3. Younger demographics and higher income are more likely to use Apple OS <br>
 - Positive attitude toward new technology, higher frequency of device updates, and more open to adopting new identifiers
4. EMEA and NAMR are more cautious about approaching new technologies <br>
 - Preference could be influenced by cultural differences and regulations
![General comfortability with adopting tech once mainstream](https://images.ctfassets.net/23aumh6u8s0i/6LXzCLV1QzEPUbZk2rh5c9/33bea12287c85db2359d9e8990a5bda4/Screenshot_2025-03-21_at_12.29.28_PM.png)
5. Top upgrade motivators are new features, device damage, battery issues, and limited memory. <br>
 - India/APAC unique concern for social brand preference and security concerns
![New features and de ice damage lead us upgrade motivators](https://images.ctfassets.net/23aumh6u8s0i/7CbnGFomOPj6PfmU4IfzeD/e92edbcce72f7994c1ca55ac4575dfa8/Screenshot_2025-03-21_at_12.30.33_PM.png)
6. Respondents who are more familiar with alternative identifiers (email and username) show higher readiness to adopt new ones. <br>
 - Apple OS users less likely to try new identifiers 
7. The most familiar and used identifiers include Email, username, phone/SMS, and biometrics. In contrast, the least used and familiar include Blockchain and hardware security keys. <br>
 - Social login is slightly more prevalent in LATAM and APAC
![APAC lead in familiarity and use for most methods](https://images.ctfassets.net/23aumh6u8s0i/71S0j1xEeG6isV67O1SwkP/4a7cdda42233bd8cc16c2a6a2f5829cf/Screenshot_2025-03-21_at_12.35.26_PM.png)
8. Username, email, and fingerprint are rated as the most convenient across all regions. <br>
 - EMEA and NAMR seem to be more sensitive to non-conventional identifiers such as government ID, security key, and voice ID, while even social login is ranked neutral. 
![Username, email, and fingerprint rated as most convenient](https://images.ctfassets.net/23aumh6u8s0i/7JSF843aMWSNsNSTxBBF0d/c1e9723a8b0efd52cc02748b81256bf6/Screenshot_2025-03-21_at_12.36.02_PM.png)
9. In contrast, Social Login is perceived as the most vulnerable to hackers and cyber-attacks. <br>
 - Our recent article, Demystifying Social Login, dives deeper into the security of leveraging Auth0 social connections for end-users. 
![Social Login seen as most vulnerable to cyberattacks](https://images.ctfassets.net/23aumh6u8s0i/7zuPvErvRjmZo3uflHsRdG/49f35a40cc73261e8d7ad06cffba6f8b/Screenshot_2024-12-17_at_10.27.55_AM.png)
10. Security and Privacy priority for motivations to try new identifiers <br>
 - NAMR and EMEA rank innovation as one of the lowest drivers
![Security and Privacy priority for motivations to try new identifiers](https://images.ctfassets.net/23aumh6u8s0i/3LpGrqWztktMy8Nw1H2lYJ/550ad822c4f8684ef18c2cea1f751d56/Screenshot_2025-03-21_at_12.34.25_PM.png)

> Download the [.CSV data here](https://cdn.auth0.com/blog/blog/End-User-Sentiments-Survey.csv).

Join the conversation! Share your thoughts, repost, and tag us to discuss the future of digital identity.

Digital Identity: What Users Think About Devices and Logins

Michelle Agroskin

Michelle Agroskin is a Staff Product Marketing Manager for Okta. She leads the Customer Identity AI, Authorization, and Consumer portfolios; driving go-to-market strategy, messaging, launches, and strategic growth initiatives.

She lives in NYC and in her free time, loves to travel the world and try new restaurants!

Staff Product Marketing Manager, Auth0

Auth0’s latest features enhance user experience with secure, customizable logins, flexible authentication, and improved security—without compromising convenience.

Customer expectations are higher than ever. They want security, convenience, and personalization, all without friction. Businesses need to deliver seamless experiences while keeping user data safe. The challenge? Balancing security with ease of access.

At Auth0, we believe you shouldn’t have to choose between security and experience. That’s why we’re introducing innovations that strengthen security and improve user experience—before, at, and after login.

## Powerful New Features for Secure, Seamless Login

Today’s businesses need to build trust with their users. Customers *expect* engaging experiences, convenient journeys, and secure digital platforms. Before they give you their business, they need to know that you can cater to their unique needs, provide ease of use across multiple channels, and protect their data and sensitive information. When security and user experience are seamlessly integrated, customers engage more, businesses grow, and digital experiences become effortless. And that starts with getting identity right. 

> We’ve updated the authentication journey to help businesses deliver trusted, customized experiences while keeping users safe.

#### **Before login**: greater flexibility with Tenant Access Control

**Security starts before users even log in. **Tenant Access Contro**l (Generally Available, March 2025) helps protect applications and APIs from threats like denial-of-service attacks. Stopping lousy traffic before it reaches your applications prevents disruptions and keeps them running. This feature allows organizations to create granular policies to manage access and mitigate threats, giving them more control over protecting their applications and users.

#### **At login**: Advanced Customization for Universal Login

**The login box is often the first interaction users have with your brand and the one they repeatedly return to as they continue engaging with it. Now, with **Advanced Customization for Universal Login** (Early Access, February 2025), businesses can control every piece of their login experience while leveraging Auth0’s security and built-in authentication process. Create pixel-perfect experiences and tailor every detail to match your brand with the same built-in security Auth0 is known for. 

#### **After login**: strengthen security

**Security doesn’t stop after users are logged in. We’re introducing key enhancements to secure the entire customer journey:

 * **FAPI 2 Certification **(Achieved, March 2025) strengthens API security with financial-grade protections that prevent transaction tampering and data leaks within our Highly Regulated Identity product.
 * **Client-initiated backchannel Authentication** (Limited Early Access, Generally Available Q2 2025) enables a client application (e.g., call center system, POS terminal, autonomous AI agent) to initiate the authentication process on behalf of the customer, making authentication easier.
 * **Native to Web SSO** (Early Access, April 2025) keeps users signed in as they move between mobile and web apps, eliminating unnecessary logins (and frustrated customers!).

## Identity Is the Key to Better Experiences 

In the past, businesses struggled with trade-offs, prioritizing security at the expense of user experience or vice versa. Modern identity removes that compromise, ensuring that security enhances, rather than hinders, customer experience.

Businesses that get identity right can deliver effortless logins, personalized interactions, and enterprise-grade security without slowing growth. These latest innovations make it easier than ever to:

* Protect against fraud and unauthorized access
* Build seamless, branded login experiences
* Maintain compliance with industry standards
* Enable flexible, secure authentication
* Keep users signed in across platforms

## Get Started Today

Auth0 makes identity **simple**, **scalable**, and more **secure.** These latest innovations help businesses stay ahead by offering users the frictionless, secure experiences they expect.

> Stop building identity from scratch. Start building with Auth0.

Learn more about these updates in our [documentation](https://auth0.com/docs/get-started) or [contact our team](https://auth0.com/contact-us) today.

_Any products, features, functionalities, certifications, authorizations, or attestations referenced in this material that are not currently generally available or, have not yet been obtained, or are not currently maintained may not be delivered or obtained on time or at all. Product roadmaps do not represent a commitment, obligation, or promise to deliver any product, feature, functionality, certification, or attestation, and you should not rely on them to make your purchase decisions._

Better User Experiences, Stronger Security

carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby and Python.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Senior Developer Advocate

Carla Urrea Stabile

Native login with passkeys is now available, so let’s take a look at how to sign up and log in on Android using Auth0’s Native Login.

How to Sign Up and Log In with Passkeys in Android Using Auth0's Native Login

Ramona-Schwering_square

Ramona, a Developer Advocate at Auth0, bridges roles as a tester and developer. She's a Google Dev Expert in Web Tech, Women Techmaker Ambassador, and Cypress Ambassador, building trust in test automation and identity topics.

Ramona Schwering

Many applications utilize Auth0 in their login procedures. However, how do you deal with that in testing? Let's learn how to cover the default login process in test automation with Cypress.

In this post, you’ll explore leveraging the Cypress testing framework to enhance security and user experience. This article is the first post of a series, which will closely examine one of the most crucial aspects: the login form and the standard login procedure.

## Why Do We Need to Mind Auth0 in Testing?

You might wonder why you should write login tests. After all, you log in to your application daily. In addition, evem more significant, Auth0's Univeral Login, thus its Login form, is already tested by the responsible teams, right? 

Well, while that's true, it's important to mind the Auth0 integration inside your application - so you're confident it's working with your application's code flawlessly. Moreover, testing the login functionality is crucial for quality assurance due to its frequent use and the significant damage that login failures can cause. Everything protected behind the login needs to be covered by tests, too. And to reach those parts of your application, you need to get through authentication via your tests as well. 

> Disclaimer: When testing Auth0’s functionality and running automated tests in a pipeline, be aware that you might use actual users, affecting your plan’s [monthly active users (MAUs)](https://community.auth0.com/t/understanding-monthly-active-users/116379). This fact is particularly relevant when registering users via automated tests. Use one dedicated test user to avoid creating too many test users and consuming your plan’s capacity.

### API Testing and Password Grant 

So, we agree that we need a solution to test the login—or at least to have a command to log in to test the behavior of your application afterward. You can imagine that this process of logging in is something you’ll do a lot when writing tests for your application, correct? In the usual case, I’d recommend including repetitive steps, such as logging in inside a [custom command](https://docs.cypress.io/api/cypress-api/custom-commands) and avoiding clicking through it, to save time. Cypress advocated for it as well. As a result, in such cases, I’d normally advocate **logging in via API and avoiding using UI through such shortcuts**. An excellent example of this approach is provided by [Cypress itself](https://docs.cypress.io/guides/end-to-end-testing/auth0-authentication#Programmatic-Login). 

However, this recommendation would require using the Password grant, which is no longer defined as OAuth 2.1, as OAuth discourages its use. These changes have significant implications for API testing, as it may no longer be a practical approach. Despite the potential time investment, we are advised to use the UI method, as we aim to avoid endorsing practices disapproved by OAuth.

## Setting Up Your Example Project

For this blog post, you'll use Cypress as the framework for your examples because it offers a robust, user-friendly solution for end-to-end testing. With its real-time reloading, detailed error messages, and intuitive API, Cypress simplifies the process of writing and running tests. Its ability to operate directly in the browser provides a clear view of how your application behaves in real-world scenarios, making it an excellent choice for ensuring your login functionality is reliable and secure. One critical approach is guiding Cypress through login forms, which is the typical method for testing this crucial feature. Fortunately, Cypress provides built-in support for handling such tests, making the process straightforward and efficient.

To help test login functionality, I recommend using a GitHub repository that hosts a clean Cypress project on the main branch. I prepared a [sample repository](https://github.com/oktadev/auth0-cypress-sample) for this blog post, which you can use for reference. 

This project is built using Cypress Version 13, ensuring you have access to the latest features and improvements. You can set up the project by cloning the repository and following the setup instructions provided, making it easy to get started with your login testing.

### Choosing a Test Base

To write a test, you naturally need some test base—something to write a test against. For this blog post, I decided to use the demo app for our virtual developer day event—[dev_day](https://developerday.com/). It took place on September 24 and offered a variety of talks, games, and other sessions, especially [labs](https://developerday.com/events/devday24/labs). Those labs are a workshop-like format, actually a guided experience to teach you Auth0's features. 

![Dev_day Demo App](https://images.ctfassets.net/23aumh6u8s0i/5uKOqkX3aDOvdODdNxMkqQ/758129b7f53b3235d9676d20b4e33bdb/Dev_day_Demo_App.png)

For those labs, we provide a Demo App showcasing all its features, which makes it perfect as a test base for our blog post.

<div className="alert alert-info alert-icon">
  <i className="icon-budicon-487"></i>
  <strong>Our Demo App's Tech Stack:</strong><br> 
The Demo app, built in React, uses NextJS to power  Frontend and Backend. The application is kept as simple as possible, e.g., by running a database based on JSON files. Of course we'll use Auth0 inside this application, together with [OpenFGA](https://openfga.dev/) <br> 
</div>

## The Standard Way of Testing Login UI

When it comes to testing your login processes, whether you’re using Auth0 or not, what comes to mind? It’s probably filling out a login form and submitting it, as this is how you’re used to login and, thus, testing it manually while coding. It might not be the most efficient way of automated testing, but let’s use it as our first example. Spoiler alert: there will be a more efficient way, but it’s essential to understand the gist of it. 

As a result, before diving into a "default" login test, let's define what we mean by "default." The typical login process consists of a form containing two input fields: an email address or username and a password. These credentials are single-factor authentication. They are sent to the server for verification; the user is granted access if successful. This is what we consider the "default" login. In testing, the user is replaced by a computer in a typical end-to-end test that clicks through a login form as a human would.

<div className="alert alert-info alert-icon">
  <i className="icon-budicon-487"></i>
  <strong>Hint:</strong><br> 
When covering a login form with tests and running them in a pipeline, know rate limits to avoid triggering them and hindering your testing efforts. Mocking responses or increasing the delay between login attempts can help circumvent this issue.<br> 
</div>

Let's start writing the test! Like any Cypress test, you'll begin with a basic test skeleton as a foundation. The following code snippet defines a test suite using Cypress to verify your application's default login flow.

```javascript
describe('Default Login Flow', () => {
    it('logs in', () => {
        cy.visit('/');
        cy.contains('Log in').click();
        cy.get('input#username').type(username);
    })
})
```

This snippet outlines a basic login flow test, ensuring the login button can be clicked and the username can be entered into the appropriate field. However, this marked line won’t work because Auth0 changes to a new domain, requiring [multi-domain testing](https://www.cypress.io/blog/cypress-9-6-0-easily-test-multi-domain-workflows-with-cy-origin) for Cypress to proceed. This kind of testing allows you to handle authentication flows that span multiple domains, which is helpful for modern web applications with third-party authentication providers.

First, set environment variables to work with Auth0’s credentials more comfortably. For this, we’ll use [dotenv](https://www.npmjs.com/package/dotenv): Install `dotenv`, and create a `.env` file in your root folder, as follows:

```
AUTH0_USERNAME=exampleusername
AUTH0_PASSWORD=examplepassword
DOMAIN=exampledomain
CLIENT_ID=examplecliendid
```

Then, you can use your environment variables and set them in `cypress.config.ts` as follows:

```javascript
import { defineConfig } from 'cypress';
import dotenv from "dotenv";

dotenv.config({ path: `.env.local` });

export default defineConfig({
    env: {
        auth0_username: process.env.AUTH0_USERNAME,
        auth0_password: process.env.AUTH0_PASSWORD,
        auth0_domain: process.env.DOMAIN,
        auth0_client_id: process.env.CLIENT_ID,
    },
    e2e: {
        // other configurations
    }
});
```

After these steps, you’re ready to start! As login steps are probably used in multiple tests, using Custom Commands to avoid duplication and keep code clean is a good practice. Create the custom command as follows:

```javascript
Cypress.Commands.add('loginToAuth0', (username, password) => {
    cy.origin(
        Cypress.env('auth0_domain'),
        { args: { username, password } },
        ({ username, password }) => {
            cy.get('input#username').type(username);
            cy.get('input#password').type(password, { log: false });
            cy.contains('button[value=default]', 'Continue').click();
        }
    );
    cy.url().should('contain', Cypress.config('baseUrl'));
});
```

Next, you'll write the custom command - where the magic's happening. 🪄 Therefore, go to `cypress/support/e2e.ts`. In it, let's create the following command stub:

```javascript
Cypress.Commands.add('loginToAuth0', (username: string, password: string) => {
  // Your custom command's steps go here...
})
```

The `cy.origin` command is used for [multi-domain testing](https://docs.cypress.io/api/commands/origin). This command will enable Cypress to handle the switch to the domain handling the login, even if it's the default Auth0 one. Let's include it inside your custom command:

```javascript
Cypress.Commands.add('loginToAuth0', (username: string, password: string) => {
  // Origin for Multidomain
  cy.origin(
    Cypress.env('auth0_domain'),
    { args: { username, password } },
    ({ username, password }) => {
      // There goes the login part
    }
  );

  cy.url().should('contain', Cypress.config('baseUrl'));
})
```

This way, we can treat the login page like our own domain - so we can make Cypress interact with it as we're used to. So finally, let's continue with our login steps we tried before:

```javascript
Cypress.Commands.add('loginToAuth0', (username: string, password: string) => {
  // Origin for Multidomain
  cy.origin(
    Cypress.env('auth0_domain'),
    { args: { username, password } },
    ({ username, password }) => {
      cy.get('input#username').type(username);
      cy.get('input#password').type(password, { log: false });
      cy.contains('button[value=default]', 'Continue').click();
    }
  );

  cy.url().should('contain', Cypress.config('baseUrl'));
})
```

Returning to your test file, use the new custom command and add assertions to check if the test logs in correctly. Here’s an example:

```javascript
describe('Default Login Flow', () => {
    it('logs in', () => {
        cy.visit('/');

        // Make sure the Login button is completely rendered and visible before interacting
        cy.get('.bg-secondary').should('be.visible');
        cy.get('.bg-secondary').click();

        cy.loginToAuth0(
            Cypress.env('auth0_username'),
            Cypress.env('auth0_password')
        );

        // Validate if the user is completely logged in
        cy.get('[href="/my-courses"]').should('be.visible');
        cy.get('.aspect-square').should('be.visible');
    });
});
```

Did you notice? I added some more assertions to make the test more stable. I'll assert on things a real user would pay attention to:
* You make sure the Login button is wholly rendered and visible before interacting to avoid flakiness
* At the end of the test, you assert two elements that are only visible if you're logged in.

Now, let's run our test and see if it's passing. 🥁

![Test is passing](https://images.ctfassets.net/23aumh6u8s0i/43XLZDtl4CX61ew9YZFdLI/21a78acffd2af12a9444dcb89bae9045/Test_is_passing.png)

That’s it! You've written a multi-domain test covering a default login process with Auth0. 🚀

### Common Issue: Hydration Errors in Cypress

As of September 2024, there's still an open [GitHub issue](https://github.com/cypress-io/cypress/issues/27204) on an error I encountered myself when working with Cypress and our dev_day Demo App:

```bash
(uncaught exception)Error: Hydration failed because the initial UI does not match what was rendered on the server. See more info here: https://nextjs.org/docs/messages/react-hydration-error.

(uncaught exception)Error: There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering.
```

This error is thus a known issue in Cypress, and we'll adjust the test to include a workaround to execute our test. It's partly based on [this response](https://github.com/cypress-io/cypress/issues/27204#issuecomment-1894217901), providing a test-wise workaround. You start by adding the following code snippet to your `cypress/support/e2e.ts` file:

```javascript
Cypress.on("uncaught:exception", (err) => {
  if (
    /hydrat/i.test(err.message) ||
    /Minified React error #418/.test(err.message) ||
    /Minified React error #423/.test(err.message)
  ) {
    return false;
  }
});
```
<div className="alert alert-danger alert-icon">
  <i className="icon-budicon-487"></i>
  <strong>Hint:</strong><br> 
It's important to mention again that it's a workaround and not an ideal one, as it conceals an error message completely - thus, it could also hide valid errors. As soon as the issue is fixed, it's highly recommended that this workaround be removed.<br> 
</div>

After applying the snippet to `cypress/support/e2e.ts`, there are still some edits we need to do in our test itself: 
We need to wait for the error to be present. This way, we time the test execution just right to have the click on the right time, targeting this error.

> (uncaught exception)Error: Hydration failed because the initial UI does not match what was rendered on the server.

To get the timing right, you can intercept the error's request and wait for it just before you click "Log In": 

```javascript
    it('logs in', () => {
      cy.intercept('/oauth/token').as('token');

      // Intercept the error message's request
      cy.intercept('/__nextjs_original-stack-frame?*').as('nextjs');
    
      cy.visit('/');

      // Wait for the error message to pop up
      cy.wait('@nextjs').its('response.statusCode').should('equal', 200);

      // Proceed with your test...
    });
```

## Some Words on Mocking

So, is there only the possibility of using UI-based end-to-end (e2e) tests, you might wonder? This does look very bleak, doesn't it? You could look at another alternative when working with third-party dependencies inside your test, including Auth0. Right, I'm talking about mocking.

Mocking in e2e tests is a practice that isolates the system under test from external dependencies. It ensures your tests run reliably, quickly, and independently of external services. However, it has a significant downside: Overuse of mocks in e2e tests could defeat the purpose of end-to-end verification by not truly reflecting real-world scenarios. Because of that, a balanced approach is vital. You need to weigh those options accordingly; it always depends on your project to decide if mocking is okay. I might answer this question in a later article regarding mocking Auth0.

## Recap

That's it. You wrote a test on Auth0's login form and workflow. Well, to be more precise, you've learned...
* ... why it's essential to consider your login inside your test, even if covered by a third party like Auth0 or you'll use it all the time
* ... About the discouragement of using password grants and the implications on API testing
* ... what Multi-Domain Testing is and how to utilize it to get through Auth0's login workflow 
* How to deal with Hydration issues inside your Cypress test in case they arise

Thanks for reading, and may your tests always stay green. 💚

How to Cover Auth0’s Login Form with Tests

37590801?s=460&v=4

A software engineer who dreams about non-electric sheep and autonomous vehicles and likes to champion security.

Software Engineer

Dan Arias

Learn how to prevent CSRF attacks from compromising your users when implementing Google OAuth for user registration and user login.

Growing an active user base is a top priority for all developers. Your product pages need copy, design, and engineering that can efficiently and effectively convert visitors into users. A visitor is an anonymous person browsing your site or app. A user is a visitor who exchanges some information to access more layers or features of your app. Even with just an email address or username, you can build a profile or identity for a user.

As such, user authentication is the backbone of conversion. User registration and login must be secure and as frictionless as possible. Long and tedious forms or requirements during registration can turn prospects away. Errors or downtime during login can frustrate even your most loyal customers, leading to dissatisfaction or support tickets.

## Why Use Google OAuth for User Authentication

A reliable way to implement user registration and authentication in an application and turn visitors into users quickly and securely is by using a registration and authentication system that your visitors already use and trust, such as Google.

As a developer, you can take advantage of Google's high security and trust Google as a source to safeguard user credentials so that you don't have to. Google social login leverages the OAuth 2.0 protocol for authorization and uses [OpenID Connect (OIDC)](https://developers.google.com/identity/openid-connect/openid-connect) as the standard for user authentication. You can delegate to Google's UI/UX and engineering the burden of password requirements, password protection, password error handling, email verification, profile data collection, and more. 

How easy or difficult is it to implement Google Login on your own? It depends. On the surface, it may be like a simple endeavor: In the JavaScript ecosystem, use a library like [`google-auth-library`](https://www.npmjs.com/package/google-auth-library), write a few lines of code, and call it a day.

While `google-auth-library` is a robust client library for using OAuth 2.0 authorization and authentication with Google APIs, it's essential to know how to use it effectively to avoid introducing security vulnerabilities in your application that could put your end-users and your organization at risk.

For instance, a recent [post on X](https://x.com/forgebitz/status/1858616526540042521) went viral: a developer named Klaas shared with the X developer community a code snippet on how to implement "google login with just the google-auth-library, no frameworks in 50 lines of code":

```typescript
export const googleLoginAction = {
  getAuthUrl: () => {
    const query = {
      client_id: oauth_google.client_id,
      redirect_uri: oauth_google.redirect_uri,
      response_type: "code",
      scope: oauth_google.scopes,
    };

    const url = new URL(oauth_google.endpoint);
    url.search = new URLSearchParams(query).toString();
    return url.toString();
  },
  verifyGoogleCode: async ({ code }: { code: string }) => {
    log.info({ code }, "verifying google auth code");

    try {
      const tokenResponse = await fetch("https://oauth2.googleapis.com/token", {
        method: "POST",
        headers: {
          "Content-Type": "application/x-www-form-urlencoded",
        },
        body: new URLSearchParams({
          client_id: oauth_google.client_id,
          client_secret: oauth_google.client_secret,
          code,
          grant_type: "authorization_code",
          redirect_uri: oauth_google.redirect_uri,
        }),
      });

      const tokenData = (await tokenResponse.json()) as { id_token: string };

      const ticket = await client.verifyToken({
        idToken: tokenData.id_token,
        audience: oauth_google.client_id,
      });

      const userData = ticket.getPayload();
      log.info({ userData }, "google auth successful");
    } catch (error) {
      log.error({ error }, "failed to verify google auth code");
      throw new Error("Failed to verify Google authentication");
    }
  },
};
```

Klaas' X post ignited a passionate discussion around user authentication and general security. As of the time of writing, the post had gathered 449k impressions, 4.7k likes, 387 reposts, and 83 comments.

## Google OAuth Implementation Can Go Wrong

Some of the commenters asked questions about the code's security posture, while others offered insights and advice on how to improve the security of that Google OAuth implementation.

Some commenters assumed the code was running on the client and were alarmed by the code handling a client secret, which could lead to a security compromise. Klaas clarified that the code is intended to run in the backend and [further explained its purpose as follows](https://x.com/forgebitz/status/1858776267266441324):

 "_this [code] has two simple functions, create a URL where you redirect the user to and a verify code function, you have the create a /callback (on the server) to get that URL. You still need to make authentication/authorization_"

Some other commenters pointed out that the code could be subject to a [Cross-Site Request Forgery (CSRF) attack](https://en.wikipedia.org/wiki/Cross-site_request_forgery), which confused others: How can there be a CSRF attack if there's no cookie involved or when the code does not run in the client?

First and foremost, let's recap what a Cross-Site Request Forgery (CSRF) attack is. [Andrea Chiarelli](https://auth0.com/blog/authors/andrea-chiarelli), Principal Developer Advocate at Okta, [summarizes a CSRF attack as follows](https://auth0.com/blog/cross-site-request-forgery-csrf/#--What-is-CSRF--):

- A typical Cross-Site Request Forgery (CSRF or XSRF) attack aims to perform an operation in a web application on behalf of a user without their explicit consent.
- The attacker leads the user to perform an action, like clicking a link.
- This action sends an HTTP request to a website on behalf of the user.
- If the user has an active authenticated session on the trusted website, the request is processed as a legitimate request sent by the user.

Andrea warns us that "even though CSRF attacks are commonly associated with session cookies, be aware that [Basic Authentication sessions](https://en.wikipedia.org/wiki/Basic_access_authentication) are also vulnerable to CSRF attacks" and that, in fact, "a CSRF vulnerability relies on the authenticated session management".

[Sandrino Di Mattia](https://x.com/sandrinodm) is a Senior Director on the Product Architecture team at Okta with robust and deep experience in cloud, identity, and security. In the thread, Sandrino commented that the code doesn’t seem to perform any state validation, making it open to CSRF attacks.

You may be wondering like others did: ["CSRF attack without any cookies, must be a new thing"](https://x.com/__morse/status/1858951728852295909). Let's explore how improperly implemented OAuth can lead to a CSRF attack.

## Cross-Site Reference Forgery (CSRF) Are Not About Cookies

Sandrino shares that CSRF is not related to cookies. Missing state validation is the most basic vulnerability in OAuth flows. [OAuth 2.0 specification recommends a `state` parameter](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1) that allows you to verify the authenticated state of your browser. The `state` parameter preserves the browser's authenticated state set by the client in an authorization request, and the authorization server makes it available to the client in the response.

[The `state` parameter helps you mitigate CSRF attacks](https://datatracker.ietf.org/doc/html/rfc6749#section-10.12) by using a unique and non-guessable value associated with each authentication request about to be initiated. That value allows you to prevent the attack by confirming that the value from the response matches the one you sent.

**But how does a CSRF attack work without cookies?**

Sandrino explains that an attacker can go through the OAuth flow but stop right when the redirect with the authorization code to the callback URL happens. Now, the attacker can send the link to the callback URL, including the code, to the victim, which consumes the code on their machine.

Depending on the implementation of your application, a few security, privacy, and data exploits could happen. For example, the attacker's account is now forced on the victim’s browser. The victim now could be uploading docs or filling in and sending personal data to the attacker's account, thinking it’s the victim's account. Or a worse scenario: the victim is already signed in, and now this new identity (the attacker's identity) is automatically linked to the victim's existing account.

## Prevent CSRF Attacks in Google OAuth

Sandrino advises us that preventing this type of attack takes a few lines of code. In practice, on redirect, you store a random value in a cookie. You then send that value to Google using the `state` param. On callback, you validate the incoming `state` parameter with the value in the cookie. If the `state` value in the response does not match the `state` value in the cookie, you reject the login operation and stop further access. The `state` parameter and PKCE can help prevent this type of attack.

> For a deep dive on this topic, you can consult the ["More Guidelines Than Rules: CSRF Vulnerabilities from Noncompliant OAuth 2.0 Implementations"](https://www.cise.ufl.edu/~butler/pubs/dimva15.pdf) paper from the Georgia Institute of Technology and the University of Florida. Check out section 3.3 on page 8.

There's a saying that goes: "You don't know what you don't know". But then, how can you know? By doing precisely what Klaas did: share code with others and be open to feedback and constructive criticism. At the same time, you can leverage the knowledge and expertise of others who have been through similar and more complex situations, which can help you avoid falling into traps or dangerous holes.

You may be thinking, "I can rely on AI for that!" You can use AI tools to learn and understand, but remember that those tools are imperfect, as they are an aggregation of human knowledge and can also make mistakes. There are instances where an AI tool can present you with "security" code with high confidence. Still, that code could be anything but secure, missing the implementation of security best practices or defensive mechanisms.

## Use Libraries to Implement Google OAuth 

It's important to highlight that if you want to implement a standard protocol yourself, you need to understand its specifications well, be aware of its nuances, and follow its details diligently. Instruments like the `state` parameter and all other security measures included in specifications and standards are the result of discussions and experience of industry experts throughout the years.

As developers, we often fall into the dilemma of reinventing the wheel (do it yourself) or relying on those who have already done it in the best way (use a library).

Sandrino suggested in the thread that it's better to use a library like Passport.js over the code shared on the tweet&mdash;or rather, X post. Passport.js implements OAuth 2.0 the way that the standard defines it. You can inspect the implementation of Google OAuth in Passport.js by looking at the [`lib/strategy.js`](https://github.com/jaredhanson/passport-google-oauth2/blob/master/lib/strategy.js) file of the [`passport-google-oauth20`](https://github.com/jaredhanson/passport-google-oauth2/tree/master) npm package.

The `OAuth2Strategy` from Passport is well-documented. The comments in the code can quickly guide you on what's happening through that flow:

- The Google authentication strategy authenticates requests by delegating to Google using the OAuth 2.0 protocol.
Applications must supply a `verify` callback function that accepts an `accessToken`, `refreshToken`, and service-specific `profile` and then calls another `cb` callback function, supplying a `user`. The `user` value should be set to `false` if the credentials are invalid. If an exception occurs, `err` should be set.

Let's see an example of how you'd use Google OAuth login with Passport.js:

```javascript
passport.use(new GoogleStrategy({
    clientID: '123-456-789',
       clientSecret: 'shhh-its-a-secret'
       callbackURL: 'https://www.example.net/auth/google/callback'
     },
     function(accessToken, refreshToken, profile, cb) {
       User.findOrCreate(..., function (err, user) {
         cb(err, user);
       });
     }
));
```

As you inspect the implementation code, you'll notice that Passport.js does much more than handle the login. [OAuth 2.0 provides consented access and restricts actions](https://auth0.com/intro-to-iam/what-is-oauth-2) of what a client app can perform on resources on behalf of the user without users ever sharing their credentials with the application. Using Google OAuth 2.0, you can also request access to user contacts and other resources on the Google platform. As the needs of your application scale, you may see yourself needing a more complex data access policy that calls for more code to write and maintain and more scenarios and edge cases to be aware of.

## Google OAuth Attacks Go Beyond CSRF Attacks

Security is an ever-evolving landscape. It's critical for you to stay on the vanguard regarding security in the industry, especially with the rise of artificial intelligence (AI). Implementing authentication on your own is an investment in money, risk, and time. Relying on robust, time-tested libraries or identity service providers can minimize some of those costs.

As mentioned in the post, implementing social login with Google OAuth for your app is just one piece of the authentication puzzle. Once you have users, you are responsible for protecting the data they entrust you. For example, depending on the region where you operate, you may be subject to regulations around user management and privacy, such as GDPR, which also extends to logs, not just the user data you have in your databases.

As you scale and grow in popularity, you may also gain unwanted attention from bad actors and attackers who may want what you are securing: rich user data. But, even on a small scale, you may become the target of bad actors looking to test their skills to break into apps.

> Recommended read: [The biggest underestimated security threat of today](https://techcrunch.com/2024/11/01/the-biggest-underestimated-security-threat-of-today-advanced-persistent-teenagers/)

In the X thread we have been discussing, Jared Hanson, the creator of Passport.js and a Principal Product Architect at Okta, validated that "checking a nonce or state is highly recommended." Jared added, "It’s less simple, but it protects against common attacks."

[Aaron Parecki](https://aaronparecki.com/), Director of Identity Standards at Okta, reminded me that it's not just CSRF attacks that are the concern when it comes to OAuth 2.0 flows. Even if you fix the CSRF attacks we have described, you could still be open to an OAuth 2.0 authorization code injection attack, which you can prevent with PKCE. You can learn more about that type of attack by watching the video below: 

<AmpContent>
<amp-youtube
    data-videoid="1ot45WwQWJE"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div className='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/1ot45WwQWJE' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

Aaron also hosted an "OAuth Happy Hour", which includes [a demo of the authorization code injection attack](https://www.youtube.com/watch?v=moQidjdV5cw). Be sure to check it out!

Let us know if you'd like a detailed follow-up blog post covering the OAuth 2.0 authorization code injection attack.

## Aside: Use Auth0 to Implement Google Social Login

Auth0 makes it even easier to get started with Google. Every new tenant has the Google social connection enabled by default. You don't even have to set up a Google Cloud project to see Google social login in action. Auth0 maintains a set of developer keys you can use to start testing Google social login in your applications in development. Follow the ["Google Social Connection to Login"](https://developer.auth0.com/resources/labs/authentication/google-social-connection-to-login#introduction) lab to learn how to use those Google dev keys and set up ones for production.


Prevent CSRF Attacks in OAuth 2.0 Implementations

Native login with passkeys allows you to integrate passkeys into your native applications and offers a smooth user experience with all the benefits of passkeys.

Native login with passkeys allows you to seamlessly integrate [passkeys](https://learnpasskeys.io/introduction) into your mobile applications. If you wanted to add passkeys before, you had to integrate a web redirect flow that uses Universal Login. 

Today, we are announcing Limited Early Access to Native Login with passkeys for Android applications. 

## How Does It Work? 

In order to use Native Login with passkeys in your Android application, there are a few requirements:

* **Enable and configure your passkey policy**: First of all, you need to enable passkeys for your tenant. Learn how to do it using [our documentation](https://auth0.com/docs/authenticate/database-connections/passkeys/configure-passkey-policy).
* **Configure a Custom Domain**: you can learn how to configure a custom domain using [our documentation](https://auth0.com/docs/customize/custom-domains).
* **Enable Android App Links Support**, which you can do following [our docs](https://auth0.com/docs/get-started/applications/enable-android-app-links-support).

Native login is available on the Android SDK from version 3.2.0 and Android API 28. 

### Sign Up 

To sign up, you’ll need to use the "`signupWithPasskey`" method from the "`AuthenticationAPIClient`". When successful, you can handle the passkey creation from your device using Android’s CredentialManager following [Android’s official docs](https://developer.android.com/identity/sign-in/credential-manager#create-passkey). Here’s an example implementation in Kotlin:

```java
val account = Auth0.getInstance("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")

val client = AuthenticationAPIClient(account) 

client.signupWithPasskey(
            UserData(
                email = "jndoe@email.com"
            ), "{realm}"  
        ).start(object : Callback<PasskeyRegistrationChallenge, AuthenticationException> {
            override fun onSuccess(result: PasskeyRegistrationChallenge) {
                val passKeyRegistrationChallenge = result
                val request = CreatePublicKeyCredentialRequest(
                    Gson().toJson(
                        passKeyRegistrationChallenge.authParamsPublicKey
                    )
                )
                var response: CreatePublicKeyCredentialResponse?

        // start credential creation on the device 
                credentialManager.createCredentialAsync(requireContext(),
                    request,
                    CancellationSignal(),
                    Executors.newSingleThreadExecutor(),
                    object :
                        CredentialManagerCallback<CreateCredentialResponse, CreateCredentialException> {

                        override fun onError(e: CreateCredentialException) {
                        }

                        override fun onResult(result: CreateCredentialResponse) {

                            response = result as CreatePublicKeyCredentialResponse
                            val authRequest = Gson().fromJson(
                                response?.registrationResponseJson,
                                PublicKeyCredentials::class.java
                            )

       // once the device created the key pair and signed the challenge you can sign in to Auth0 
                            client.signinWithPasskey(
                                passKeyRegistrationChallenge.authSession,
                                authRequest,
                                "{realm}"
                            )
                                .validateClaims()
                                .start(object : Callback<Credentials, AuthenticationException> {
                                    override fun onSuccess(result: Credentials) {
                                        credentialsManager.saveCredentials(result)
                                        Snackbar.make(
                                            requireView(),
                                            "Hello ${result.user.name}",
                                            Snackbar.LENGTH_LONG
                                        ).show()
                                    }

                                    override fun onFailure(error: AuthenticationException) {
                                        Snackbar.make(
                                            requireView(),
                                            error.getDescription(),
                                            Snackbar.LENGTH_LONG
                                        ).show()
                                    }
                                })
                        }
                    })
            }

            override fun onFailure(error: AuthenticationException) {
                Snackbar.make(
                    requireView(),
                    error.getDescription(),
                    Snackbar.LENGTH_LONG
                ).show()
            }
        })
```

The `signupWithPasskey` method starts the passkey creation ceremony. It generates the challenge for the authenticator to sign once it has created the public key credential pair. In your case, your Android device acts as the authenticator and you create the key pair and sign the challenge when you use the `CreatePublicKeyCredentialRequest` method from Android’s Credential Manager. 

Then, you can use Android’s Credential Manager method `createCredential` or `createCredentialAsync` to start the creation. Once successful, you can use the result from the creation to send that data to Auth0 and sign in using the ``signinWithPasskey`` method, which is covered below.

### Login 

To sign in, you’ll have to first initiate the passkey challenge by using the `passkeyChallenge` method from the `AuthenticationAPIClient`. When the call is successful, you can initiate the credential retrieval using Android’s [`getCredential` method from the `CredentialManager`](https://developer.android.com/identity/sign-in/credential-manager#sign-in).

When your device retrieves the credential successfully, you can then initiate the sign-in process with Auth0. An example implementation could be:

```java
val account = Auth0.getInstance("{YOUR_CLIENT_ID}", "{YOUR_DOMAIN}")
val client = AuthenticationAPIClient(account)

client.passkeyChallenge(realm)
            .start(object : Callback<PasskeyChallenge, AuthenticationException> {
                override fun onSuccess(result: PasskeyChallenge) {
                    val passkeyChallengeResponse = result
                    val request =
                        GetPublicKeyCredentialOption(Gson().toJson(passkeyChallengeResponse.authParamsPublicKey))
                    val getCredRequest = GetCredentialRequest(
                        listOf(request)
                    )
                    credentialManager.getCredentialAsync(context,
                        getCredRequest,
                        CancellationSignal(),
                        executor,
                        object :
                            CredentialManagerCallback<GetCredentialResponse, GetCredentialException> {
                            override fun onError(e: GetCredentialException) {
                                Log.w(TAG, "Error fetching public key credential")
                                callback.onFailure(handleGetCredentialFailure(e))
                            }

                            override fun onResult(result: GetCredentialResponse) {
                                when (val credential = result.credential) {
                                    is PublicKeyCredential -> {
                                        val authRequest = Gson().fromJson(
                                            credential.authenticationResponseJson,
                                            PublicKeyCredentials::class.java
                                        )
                // initiate signin process with Auth0
                                        client.signinWithPasskey(
                                            passkeyChallengeResponse.authSession,
                                            authRequest,
                                            realm
                                        )
                                            .validateClaims()
                                            .addParameters(parameters)
                                            .start(callback)
                                    }

                                    else -> {
                                        Log.w(
                                            TAG,
                                            "Received unrecognized credential type ${credential.type}."
                                        )
                                        callback.onFailure(AuthenticationException("Received unrecognized credential type ${credential.type}"))
                                    }
                                }
                            }
                        })

                }
```

For more detailed examples, you can check out the [Android SDK sample folder on Github](https://github.com/auth0/Auth0.Android/tree/main/sample).

If you need [Java examples, you can check out this doc](https://github.com/auth0/Auth0.Android/blob/main/EXAMPLES.md#passkeys).

## What Use Cases Are Supported?

The initial early access release provides support for the following use cases:

* **Sign Up with a passkey**: users can register a new passkey for Auth0/your app and store it in the device credential manager for future use. 
* **Login with a passkey**: users can retrieve passkeys using the device’s credential manager and use them to log in. 

## How Can You Apply?

If you are interested in joining the early access program, please reach out to your account manager.

_Any products, features, or functionality referenced in this material that are not currently generally available may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation, or promise to deliver any product, feature, or functionality, and you should not rely on them to make your purchase decisions._

Native Login with Passkeys Is Now in Limited Early Access for Android Applications!

amanda-giannelli

Senior Software Engineer

Amanda Giannelli

Simplify logins, boost security, and enhance productivity with the power of Single Sign On!

## Introduction

Are you tired of juggling a bunch of usernames and passwords just to get your work done? You’re not alone. In today’s world, where we use so many different apps and services, keeping track of login details can feel like a full-time job. 

Enter Single Sign On (SSO), a simple yet powerful solution that lets you access all your apps with just one login. Let’s dive into what SSO is and why it’s such a game-changer for businesses.

## What is SSO?

You may have already used SSO without realizing it. Whenever you log into a website that leverages [identity providers](https://auth0.com/docs/authenticate/identity-providers) such as Google, Facebook, or Apple (to name a few), that is single sign-on in action.

SSO is a fancy term for a straightforward concept: log in once, and you’re good to go across all your apps. Whether it’s checking your email, collaborating on a project, or logging into your CRM with SSO, one login gets you everywhere you need to be. It’s like having an all-access pass to everything you need for work.

## How Does SSO Work? 

When SSO is enabled, and you attempt to authenticate to App A, you are sent to the authentication server to provide your credentials. Once authenticated, you are redirected back to App A and signed in. If you then access any other services (for example, another app) connected to the same auth server, you will be immediately authenticated into this application.

![SSO authentication and how it works](https://images.ctfassets.net/23aumh6u8s0i/1rHF8E9UCO7abbWzLRntV0/6856815f4ee9b078d83093d2a21a6bc7/typical-sso.png)

> Read more about [SSO authentication and how it works](https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/). 

## Benefits of SSO

Now that you have a general understanding of what SSO is, let’s take a look at some of the benefits.

### Enhanced User Experience

Remembering a bunch of different passwords is a hassle. With SSO, you only need to remember one password. No more struggling to recall if your password for App A has a special character or if App B requires an uppercase letter. Log in once, and you’re in — it’s that simple.

#### Goodbye, Password Overload

Keeping track of passwords can feel overwhelming. While a password manager is an option, SSO puts an end to needing scores of passwords. By reducing the number of passwords you have to remember, it’s less likely you’ll get locked out or end up using the same password everywhere (which, let’s be honest, [isn’t very safe](https://www.security.org/resources/online-password-strategies/)).

#### Get to Work Faster

SSO saves you time. Instead of typing in different credentials every time you switch apps, SSO gives you instant access. It’s like walking through an open door instead of fumbling for keys — you get to work faster and with less hassle.

SSO providers also typically provide a dashboard with all of the apps you have access to. Open the dashboard, select your app, and you’re in. 

### Boost Security

You might think that having one login for everything sounds risky, but SSO actually makes your business more secure. Here’s how:

#### One Secure Login Point

With SSO, all your logins are managed in one place. This means your IT team can keep a close eye on things and quickly respond if something looks suspicious. It’s like having all your valuables in one safe instead of scattered around the house.

#### Reduced Chance of Phishing 

[Phishing scams](https://auth0.com/blog/protecting-against-phishing-attacks/) — fake emails trying to steal your info — are a big problem. But with SSO, you’re not entering your password over and over, so you’re less likely to fall for a phishing trap. Fewer logins mean fewer chances for scammers to trick you.

#### Add Extra Security with MFA

Most SSO solutions let you add [Multi-Factor Authentication](https://auth0.com/docs/secure/multi-factor-authentication) (MFA), which provides another layer of security by requiring more than just a password to log in. Maybe you’ll need to enter a code sent to your phone or scan your fingerprint. This extra step makes it much harder for hackers to get in, even if they have your password.

### Lighten the Load on Your IT Team

SSO isn’t just great for users. It's also a lifesaver for your IT department. Managing user accounts and passwords can be a real headache, but SSO makes it a breeze.

#### Easier User Management

With SSO, your IT team can manage who has access to what from a single dashboard. Need to give new employees access to all the tools they need? Done in a few clicks. Need to remove access when someone leaves? Just as easy. It’s all centralized, which saves time and reduces errors.

#### Fewer Helpdesk Calls

Did you know that [up to 50% of helpdesk calls](https://agio.com/your-employees-are-wasting-30-of-their-time-resetting-passwords/) are for password resets? SSO cuts down on the need to [reset your password](https://auth0.com/learn/password-reset), freeing up your IT team to focus on bigger issues and your employees to work on what truly matters. Less time resetting passwords means more time to solve real problems.

#### Smooth Compliance and Reporting

If your business is in a regulated industry (such as finance or healthcare), SSO can make compliance a lot easier. It keeps detailed logs of who accessed what and when, so when it’s time for an audit, you’ve got everything you need at your fingertips.

### Scale Up with Ease

As your business grows, so do your tech needs. The good news? SSO grows with you. Whether you’re adding new apps or expanding your team, SSO makes it easy to scale up.

#### Integrates with What You Already Have

SSO solutions are designed to work with the tools you’re already using, whether they’re in the cloud, on your servers, or a mix of both. So, no need to overhaul your entire system — just plug SSO in and keep moving forward.

#### Works Across All Environments

Many businesses today use a mix of on-premises and cloud-based applications. SSO bridges the gap, providing a seamless login experience across all platforms. So, as you move more of your operations to the cloud, SSO keeps everything running smoothly.

#### Future-Proof Your Business

By implementing SSO, you’re setting your business up for success as you grow. No matter how many new apps or services you add, SSO will be there to keep everything secure and accessible, ensuring your team can stay productive without getting bogged down by tech hurdles.

### Better Collaboration with Partners

If your business works with external partners or clients, SSO can make those relationships smoother and more secure. Here’s how:

#### Secure Partner Access

SSO lets you extend secure access to your partners without compromising your internal security. You control who sees what, so everyone has the access they need — and nothing more.

#### Easier Collaboration

When your partners can log in easily without juggling multiple credentials, it’s easier to work together. Whether you’re sharing documents or managing a project, SSO makes collaboration a breeze.

### Challenges

For all of its amazing benefits, SSO is not without its challenges. Understanding these considerations can help you plan effectively and ensure that your SSO implementation is successful. Here are a few to keep in mind:

#### Single Point of Failure

SSO centralizes authentication, so if the SSO system goes down, users may lose access to all connected applications. This is why high availability coupled with redundancy for your SSO solution is critical to reduce downtime. High availability means the system is always on and available no matter what happens. Redundancy enables high availability by acting as a backup plan in the event of failure to ensure the services remain functional. 

#### Setup and Integration

Integrating SSO into existing applications can be complex and time consuming, especially when dealing with a mix of legacy and new systems. Careful planning and coordination between IT teams and application owners is crucial to ensure a smooth implementation.

#### Security Risks

While SSO can enhance security, it can pose a risk if not properly managed. If an attacker gains access to a user’s SSO credentials, they could potentially access multiple applications. Implementing strong authentication methods, such as MFA, is essential to mitigate this risk. 

#### User Adoption and Training

Users need to be educated on how SSO works and the importance of keeping their credentials secure. Without proper training, there may be confusion or resistance — especially in less tech-savvy organizations. 

## Conclusion

SSO isn’t just a buzzword. It’s a powerful tool that can make your business more efficient, secure, and scalable. By simplifying the login process, reducing security risks, and lightening the load on your IT team, SSO can help your business thrive in today’s fast-paced digital world.

If you’re not using SSO yet, now’s the perfect time to start. Whether you’re a small business looking to grow or an established company ready to streamline operations, SSO can give you the boost you need to stay ahead of the curve.

Benefits of Single Sign-On (SSO)

joey devilla headshot 900px

I’m a Senior Developer Advocate at Auth0, and I like to work on various technologies. I’ve developed software for all sorts of platforms, from CD-ROM and the PalmPilot to my current area of focus, mobile phones, IoT devices, and AI. When I’m not looking for strange new platforms to write software for, I’m playing a strange old instrument — the accordion!

Joey deVilla

peterfernandez_360

As an Architect, Consultant, and Engineer, I have more than 30 years of experience designing and developing secure and robust software solutions. When not helping teams deal with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.

Peter Fernandez

Learn how to add authentication (login and logout) to iOS apps built with SwiftUI with Auth0 and the Auth0.Swift package.

Get Started with iOS Authentication using SwiftUI, Part 1: Login and Logout

I stream, blog, and make youtube videos about tech stuff. I love coding, I love AI, and I love building stuff!

Staff Developer Advocate

Juan Cruz Martinez

This guide shows you how to permit or deny login requests by utilizing deny or allow lists. With step-by-step instructions, you'll create a new Auth0 Action, work with lists, and delegate list management to an external API.

Auth0 provides a robust set of tools and features to enhance authentication and authorization in applications. One such feature is Auth0 Actions, which allows you to customize and extend the behavior of the Auth0 platform. This article will explore using Auth0 Actions to permit or deny login requests based on specific criteria, such as a denied and allowed list.

## Prerequisites

Before diving into the implementation, there are a few prerequisites to ensure you have in place. 

- **Auth0 account.** If you don’t have one already, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free Auth0 account</a>.
- **Basic JavaScript knowledge**: Auth0 Actions are functions you can program using JavaScript. In this tutorial, I’ll provide you with the examples. However, to further customize them for your use case, it is important to have basic JavaScript knowledge.

## Create a New Action

To begin, let's create a new [Auth0 Action](https://auth0.com/docs/customize/actions/actions-overview). Actions are serverless functions that run in a secure Auth0 environment.

To create an Action, log into your [Auth0 Dashboard](https://manage.auth0.com/#/actions/flows), select Actions from the left sidebar menu, then select Flows. This page shows the different flows you can customize. For our use case, we’ll choose the “Login” flow.

![The “Actions” page of the Auth0 dashboard.](https://images.ctfassets.net/23aumh6u8s0i/6Urd7xOI45T2kfVRnSYVfg/2deba4f6affc4cf234e5874d99999ba2/select_the_login_flow.png)

This will take you to the “Login” flow page, where you can install, create, and add Actions to the flow.

![The “Login” flow page of the Auth0 dashboard.](https://images.ctfassets.net/23aumh6u8s0i/7lgp4OyGh5EigXd8W6yZ8n/6c9dd5f1b3a162d8654fd97dcb629369/login_flow_page.png)

The screen has two main sections, the diagram in the center of the page shows the login flow and the Actions panel.

On the diagram, we can see the default login flow, which contains two states.

- **Start:** The user completed the login form and is ready to log in.
- **Complete:** The system issues the user’s credentials (an ID token and, if required, an access token).

You can drag and drop Actions in between these states to add custom logic to the login flow or to even deny the login request before the tokens are issued.

On the right panel, we have the Actions panel with two tabs.

- **Installed**: Pre-installed Actions from the [Auth0 Actions Marketplace](https://marketplace.auth0.com/features/actions)
- **Custom:** Actions created for this tenant

To create an Action, click the plus icon on the Actions panel and select "Build Custom".

![Create a custom Action using the Actions panel](https://images.ctfassets.net/23aumh6u8s0i/4AlGcWH9I7XWxYaG9BGpgt/7bc82776e321c1fe97b3e91a06667439/add_action.png)

After that, a modal window will appear to enter the information for our Action: you’ll have to provide a name, and you can leave the trigger and runtime as the default values. For my Action, I’ll name it “Validate User Login”.

![Enter the Action name and click create](https://images.ctfassets.net/23aumh6u8s0i/54faDAu75f8xpX1WjMnblt/717dd9e1d20658fedcc03e8271f64143/create-auth0-action-modal.png)

After clicking on "Create", you’ll be taken to the Action’s code editor, where you can write the code for your Action, install packages, test it, and more:

![Auth0 Actions code editor page](https://images.ctfassets.net/23aumh6u8s0i/5qe9QL6Iefmin0HFmRyQ5A/376010f5d460bbc7c034ad644f0543e7/auth0-actions-code-editor.png)

An Action can make use of two JavaScript functions to alter the Login flow:

- `onExecutePostLogin`: defines what should happen immediately after the user provides login credentials that Auth0 verified. This method receives two parameters, `event` and `api`.
    - `event`: contains details about the login request, such as the user and the context.
    - `api`: contains methods to manipulate the login’s behavior.
- `onContinuePostLogin`: defines what should happen when control returns to the Login Action after a redirect to another web page. It’s used only when the user returns after being redirected, which is why it’s commented out by default.

For this tutorial, we’ll focus on the `onExecutePostLogin` method.

## Working with a Deny List

A deny list is a common way to block specific users or IP addresses from logging in. To implement a deny list using Auth0 Actions, you can leverage the context available to the Action's code through the `event` parameter. The `event` object contains information about the incoming authentication request, such as user details and IP address. By accessing this object, you can compare the values against your deny list and take appropriate action just as denying the authentication request.

Before we start writing the code for our deny list, we need to know how to cancel the user’s login request. For that, we make use of the `api` parameter as follows:

```javascript
api.access.deny('reason');
```

With a single line of code, we can deny the login request. The `deny` method expects a single parameter `reason`, which is a human-readable explanation for the rejection.

Now, let’s start updating our function to support a deny list:

```javascript
// Array containing the email addresses that are blocked from logging on.
const denyList = ['myemail@example.com']

exports.onExecutePostLogin = async (event, api) => {
  if (denyList.find(email => email === event.user.email)) {
    api.access.deny("Your email address is blocked from logging in to our systems.");
  }
};
```

In this simple function, we have a hardcoded list of email addresses that are forbidden from logging in to our system, and the `onExecutePostLogin` simply looks if the user’s email address on the login event is in the list. If so, it denies the user’s access.

Once you add the code to the Action’s editor, it’s time for testing, and the best way to do it while in development mode is with the test panel.

You can access the test panel by clicking the play button on the editor’s sidebar, as shown below:

![Access the Auth0 Actions test panel by clicking the play button on the left sidebar](https://images.ctfassets.net/23aumh6u8s0i/5aZkR41jz9C6UjtuZizGCm/26ec7df5b28c78639e4701a1624a2dad/actions-test-panel.png)

Once you expand the panel, you can customize a test event object to your needs; for example, you can look for the `user` object, which contains all user properties such as `given_name`, but more importantly for our use case, `email`.

By clicking the "Run" button at the bottom of the test panel, Auth0 will execute the Action on the given data and output the test results on the test result window. If the given user is not part of our denied list, you’ll see the following test output:

![Auth0 Action’s test result for a successful execution](https://images.ctfassets.net/23aumh6u8s0i/2pX163YMm8dq9OPvbMIXz9/37f82cec86640e560a4bb2fd3543074d/auth0-action-ok-test-result.png)

On the contrary, if you update the event JSON to include one of the denied user email addresses, you’ll receive the following test output:

![Auth0 Action’s test result for a denied request](https://images.ctfassets.net/23aumh6u8s0i/7xGybOaomBF6ghtsP6l0i8/485440622fc08629927fae8eb3b820e8/auth0-action-denied-test-result.png)

Finally, once you complete your testing, you can deploy the function so it is available to add to the login flow.

## Working with an Allow List

On the other hand, an allow list specifies the users or IP addresses that are explicitly permitted to log in. Like working with a deny list, you can access the necessary information using the `event` object. Compare the values against your allow list and proceed with the login flow only if the user or IP address is found on the list. Otherwise, you can deny access by rejecting the authentication request.

Similarly to the deny list, the allow list will use the `deny` method to reject all requests except those from users in the allow list.

Here is the new code:

```javascript
// Array containing the email addresses that are allowed to log in.
const allowList = ['myemail@example.com', 'j+smith@example.com']

exports.onExecutePostLogin = async (event, api) => {
  if (!allowList.find(email => email === event.user.email)) {
    api.access.deny("Your email address is not authorized to log into our systems.");
  }
};```

Running the tests, as previously explained, should give similar results following the corresponding logic.

## Delegate List to an API

If you have many entries in your denied or allowed list, storing and managing the list in an external system, such as a database or an API, might be more practical. With Auth0 Actions, you can delegate the list retrieval and verification to an external API. Within your Action's code, make the necessary API calls to verify the user's status and subsequently reject or allow the authentication request.

For this exercise, we'll assume that you already have an API endpoint that, given a user's email address, will return if the user is authorized to access. Here is an example of what such an API could look like:

```bash
curl https://myaccessapi.com/users/is_authorized?email=myemail@example.com
{
  is_authorized: false
}
```

Given this simple example, let’s update our code:

```javascript
const axios = require('axios');

exports.onExecutePostLogin = async (event, api) => {
  const auth_result = await axios.get(`https://myaccessapi.com/users/is_authorized?email=${event.user.email}`)
  if (!auth_result.is_authorized) {
    api.access.deny("Your email address is blocked from logging in to our systems.");
  }
};
```

Note that for calling an API, we are using the `axios` library, which is already available in your Actions environment. If you need access to other dependencies, you can simply add npm dependencies as part of your Actions bundle. You can learn more about dependencies on Actions on the [official documentation](https://auth0.com/docs/customize/actions/manage-dependencies).

## Attach an Auth0 Action to the Login Flow

After coding and testing your Actions, it’s time to deploy and use them as part of the login flow. Once you are ok with your testing results, you can hit the `Deploy` button on the top right corner of the screen. This will take the existing code and settings and generate a function snapshot you can use in your login flow.

If you ever need to change the code on the function, all changes will automatically be saved as a new draft, and if you want the changes to become effective, you’ll have to deploy your latest version once again.

Once your code is deployed, it doesn’t mean it is actively used as part of your login flow. To check for that, please refer back to the [login flow screen](https://manage.auth0.com/#/actions/flows/login/), where the login diagram is shown. If you don’t see your Action as part of the diagram, it means that, even if your Action is deployed, it has not yet been activated. To activate the Action as part of the flow, click on the “Custom” tab on the Actions panel, locate your Action by name, and simply drag and drop the box over the login diagram between the "Start" and "Complete" steps. After that, you can apply changes using the “Apply” button on the top right corner of the screen.

![Apply an Auth0 Action to the Login Flow](https://images.ctfassets.net/23aumh6u8s0i/eHb4lOXaXYvG3EdaVt6xM/aed46e987226df5b8ff5d41b03fd882c/apply-action-to-flow.gif)

## Summary

This article explored how to leverage Auth0 Actions to permit or deny login requests. By using a deny list or an allow list, you can enhance the security of your application and control access based on specific criteria. We also discussed delegating the list management to an external API, providing scalability and flexibility. With Auth0 Actions, you have the power to customize the login flow and add an additional layer of security to your application.

The examples I provided throughout the article are a good starting point. However, you can further customize them to meet your needs. For instance, you could use allow/deny lists by domains instead of emails or by IP addresses, country, day and time, etc.

Always thoroughly test your implementation and consider any potential edge cases specific to your application's requirements. By using Auth0 Actions effectively, you can ensure a robust and secure authentication experience for your users.

Thanks for reading!

Permit or Deny Login Requests Using Auth0 Actions

Learn how to create customizable and secure login pages that match your branding to enhance user experience and conversion rates.

So, you've built an outstanding application. Your landing page is meticulously designed, compelling, and has a high conversion rate. You've carefully crafted every detail of the user experience, but what about the entry points to your app – the signup and login pages?

Often overlooked in the design process, these critical touchpoints serve as the users’ gateways into your application. They should be as compelling, user-friendly, and beautiful as the rest of your application. Just as the landing page captures the user's attention, the login and signup pages are where you can truly start to engage users, encouraging them to join your application.

In this article, we'll explore how Auth0 makes it easy to build login and signup experiences that not only align seamlessly with your branding but also provide a superior user experience. A poorly designed login page can lead to user frustration and higher abandonment rates, whereas a well-designed one establishes trust and encourages engagement. Because every aspect of your application, even the seemingly mundane, should be nothing short of beautiful.

Let's dive into how Auth0 can elevate your login experience, covering the importance of UI and UX, and offering practical tips to create extraordinary login flows.

## The Importance of the Login Page Design

The login page is often the first impression a user has of your application. It sets the tone for the entire user experience and can make or break a user's decision to continue using your app.

The design of a login page encompasses both UI and UX. It should not only be pretty but also easy to use while conveying a sense of security and trustworthiness to the user.

If you need inspiration or to learn some tips on what makes good login pages extraordinary, check out these [ten tips](https://www.invisionapp.com/inside-design/login-page-design/).

## Getting Started

Auth0 offers a variety of [customization options to match your application's branding and design](https://auth0.com/blog/customize-auth0-universal-login-with-auth0-cli/). With Auth0, you can rest assured that your login and signup pages will be not only beautiful and match your brand but also secure and reliable.

In many scenarios, those out-of-the-box settings are all you need to make your login and signup pages match your brand and style. But in case you want a completely customized page, Auth0 offers the possibility to create your own styles and designs using [HTML, CSS, and JavaScript templates](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates). 

> Custom templates require enabling [custom domains](https://auth0.com/docs/customize/custom-domains), which is a paid feature.

In this article, we’ll focus on creating our own template to have full control over the login experience. However, if you would like to know how to set up your branding settings instead, you can refer to this article on [Customize Auth0 Universal Login with Auth0 CLI](https://auth0.com/blog/customize-auth0-universal-login-with-auth0-cli/).

You can work with templates either through the [Auth0 Dashboard](https://manage.auth0.com/#/login_page) with an integrated code editor and preview mode, or you can use the [Auth0 CLI](https://github.com/auth0/auth0-cli) with your editor of choice and [Storybook](https://storybook.js.org/) to preview your designs.

Throughout the article, we'll use the Auth0 CLI to customize the templates as it provides a rich developer experience.

## Setting up the Auth0 CLI

The Auth0 CLI is a powerful tool that allows you to manage your entire Auth0 tenant from the command line. The Auth0 CLI helps you simplify your workflows and set up automation on your Auth0 account.

### Install the Auth0 CLI

The Auth0 CLI is available for macOS, Linux, and Windows. To install it on your preferred OS, please follow [these installation instructions](https://github.com/auth0/auth0-cli#installation).

After your installation completes, you can verify the installation by running the following command:

```bash
auth0 -v
```

### Connect the CLI to your Auth0 Account

To connect the CLI to your Auth0 account, you'll need to log in. Run the following command in your terminal and follow the instructions to authenticate:

```bash
auth0 login
```

First, the CLI will prompt for one of two authentication methods, `As a user` or `As a machine`. For now, we’ll select `As a user` since it is the recommended option for a personal computer. However, for automation scenarios, it is recommended to select the latter.

Next, we need to authenticate in the browser using [device authorization flow](https://auth0.com/docs/get-started/authentication-and-authorization-flow/device-authorization-flow). The Auth0 CLI will show a code on the screen and will open a browser session, where the code should match, and after verification, you’ll have to authorize the CLI on all the requested scopes.

## Activate a Custom Domain

As mentioned before, a requirement for editing custom templates is to activate custom domains, which is a good practice for production. Since custom domains come in different configurations and multiple steps, I won’t be covering them in this article. Instead, I can refer you to the [custom domains documentation](https://auth0.com/docs/customize/custom-domains), where you can find all the information you’ll need with step-by-step instructions.

Once you have a custom domain set up on your account, you can continue with the rest of the article.

## Customizing the Universal Login UI

To start customizing the Universal Login UI, run the following command on your terminal:

```bash
auth0 universal-login customize
```

This will open the Auth0 customization editor on your browser which will allow you to change any visual settings in Universal Login, from colors, logo, texts, and you can design your own templates with live preview in this app.

![Auth0 Universal Login Editor Preview](https://images.ctfassets.net/23aumh6u8s0i/5YNs9FYoGfPXrMon6OMpkY/88008ca9b492268c60724883011271f0/Screenshot_2024-04-18_at_09.41.25.png)

Any changes that you make locally can then be deployed to your Auth0 tenant from the same UI.

### Exploring the UI

The UI customization tool is divided into three sections:

- **Navigation bar**: It allows you to work on different areas of customization, from settings, theme, page template and custom texts. It also allows you to navigate through the different prompts like login, signup, etc.
- **Editor**: On the left side, it's the editor. It will display information about the current state of your page in either JSON for settings or HTML code for the page template editor.
- **Preview window**: The preview window gives you a live preview of your changes and how your UL page will look like when deployed to your tenant.

## Building a Beautiful Template

If you jump into the **Page Template** section, the editor will load the current template available for your tenant. If you have never customized your template, it will display the default template which looks like this:

```html
<!DOCTYPE html>
<html>
  <head>
    {%- auth0:head -%}
  </head>
  <body>
    {%- auth0:widget -%}
  </body>
</html>
```

There's some custom code in that template, let's explore what each of those sections do:

- `{%- auth0:head -%}`: This will set all the head elements that are required for universal login to work, like importing scripts, basic styles, etc.
- `{%- auth0:widget -%}`: This will place the login widget on the screen.

Templates use [Liquid syntax](https://shopify.github.io/liquid/basics/introduction/), with variables you can use to further customize your experience. You can read about all variables available [here](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates).

One of the benefits of using Auth0's rich templating system is the ability to customize logic depending on the current prompt. For example, you could have some parts of the UI shown on the signup screen but not on the login or other prompts. The term prompt is used to refer to a specific step in the login flow. Each prompt can have one or more screens. For example, the `reset-password` prompt would have multiple screens for resetting password requests, checking your email, entering a new password, and confirming your change. You can find the complete list of prompts and screens on the [official template variables documentation](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates#:~:text=screen%20being%20rendered.-,The%20term%C2%A0prompt,-is%20used%20to).

You can do that by implementing conditionals over the variable `prompt.name`. Here's an example that renders additional content when the user is signing up.

```text
{% if prompt.name == "signup" %}
Show this only if the user is signing up
{% end %}
```

As part of templating, you can also set custom brand parameters, such as the brand's primary color, background, and logo, which you can use throughout the template by accessing the `branding` variable.

For example, if you need a button that aligns with the branding's primary color, you could implement it as follows:

```html
<button style="background-color: {{branding.colors.primary}}" ...>My Button</button>
```

Now that we know what we can do with the templating system, it's time to build your own.

Here's what I'll build. Feel free to copy and paste this template and customize it to your application or use it as a baseline for your own.

- Signup screen:
	![Custom Signup Screen](https://images.ctfassets.net/23aumh6u8s0i/5u5pK7O3FLMInWmakSjRAr/99dce5b115abc63d90ea271440f1afa6/custom-template-signup.png)
- Login screen:
	![Custom Login Screen](https://images.ctfassets.net/23aumh6u8s0i/3dzWx5rQ3xiIgqUTyBTqXT/0fee59fa6b4f593f5771ed4e25d8100d/custom-template-login.png)

What’s interesting about this design is that the signup page looks different from the rest as it provides additional information about the product, so users know what they are signing up for. I also make use of variables to set the branding color on custom elements and I added some responsive elements for tablets and mobile devices.

Here is my template for your reference:

```html
<!DOCTYPE html>
<html>
  <head>
    {%- auth0:head -%}

    <style>
        body {
            background-color: #fff;
        }

        .wrapper {
            max-width: 80rem;
            margin: 0 auto;
        }

        {% if prompt.name == "signup" %} 
        .container {
            width: 100%;
            height: 100vh;
            display: grid;
            grid-template-columns: 1fr 1fr;
            align-items: center;
        }

        @media screen and (max-width: 720px) {
            .container {
                display: flex;
                flex-direction: column;
            }
        }

        .container > .info {
            max-width: 28rem;
            padding: 1rem;
        }
        {% else %}
        .container {
            width: 100%;
            height: 100vh;
            display: flex;
            align-items: center;
            justify-content: center;
        }

        .container > .info {
            display: none;
        }
        {% endif %}

        .container > .info h2.title {
            font-size: 3rem;
            line-height: 1.2;
            margin-bottom: 1.5rem;
            font-weight: bold;
        }

        .container > .info p.subtitle {
            color: #718096;
        }

        .container > .info ul {
            list-style-type: none;
            margin: 0;
            padding: 0;
        }
        
        .container > .info li {
            color: #1A202C;
        }

        .container > .info li svg {
            color: #5CC98D;
            vertical-align: text-bottom;
            margin-top: 1.5rem;
        }

        .container > .login-box {
            position: relative;
            display: flex;
            align-items: center;
            justify-content: center;
            padding: 0 4rem;
        }

        .container > .login-box svg {
            position: absolute;
            width: 100%;
        }
    </style>
  </head>
  <body>
    <div class="wrapper">
        <div class="container">
            <div class="info">
                <h2 class="title">My Product</h2>
                <p class="subtitle">My product is awesome and it offers the following features:</p>
                <ul role="list">
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 1
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 2
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 3
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 4
                    </li>
                    <li>
                        <svg stroke="currentColor" fill="currentColor" stroke-width="0" viewBox="0 0 24 24" focusable="false" role="presentation" height="1em" width="1em" xmlns="http://www.w3.org/2000/svg"><path d="m10 15.586-3.293-3.293-1.414 1.414L10 18.414l9.707-9.707-1.414-1.414z"></path></svg>
                        Feature 5
                    </li>
                </ul>
            </div>
            <div class="login-box">
                <svg width="1013" height="890" viewBox="0 0 1013 890" fill="none" xmlns="http://www.w3.org/2000/svg">
                    <path d="M180.462 795.681L40.8315 567.776C19.5801 533.09 8.95466 515.747 4.64446 497.091C0.831363 480.586 0.608543 463.413 3.99145 446.712C7.81567 427.835 17.9843 409.924 38.3214 374.102L184.235 117.101C203.682 82.8483 213.405 65.722 227.028 52.9648C239.084 41.6743 253.303 32.9153 268.81 27.225C286.332 20.7958 306.003 19.8141 345.345 17.8502L644.507 2.91668C685.874 0.851143 706.557 -0.18069 725.22 4.94606C741.731 9.48141 757.023 17.479 770.074 28.4042C784.827 40.7544 795.51 58.1913 816.877 93.066L955.838 319.878C977.009 354.434 987.595 371.712 991.91 390.3C995.728 406.747 995.98 423.86 992.649 440.515C988.883 459.337 978.815 477.215 958.678 512.969L811.011 775.156C791.315 810.127 781.466 827.612 767.593 840.563C755.316 852.023 740.811 860.86 724.997 866.515C707.127 872.905 687.074 873.638 646.968 875.103L350.229 885.943L350.228 885.944C309.449 887.433 289.06 888.178 270.689 882.944C254.434 878.313 239.396 870.318 226.557 859.48C212.045 847.23 201.517 830.047 180.462 795.681Z" fill="{{branding.colors.primary}}"/>
                    <path d="M179.711 769.196L58.7659 539.848C40.3585 504.942 31.155 487.489 28.2839 469.088C25.744 452.808 26.7984 436.065 31.3778 419.97C36.5543 401.778 47.9229 384.859 70.66 351.022L233.792 108.259C255.534 75.9041 266.405 59.7266 280.801 48.0099C293.543 37.6402 308.23 29.8499 323.963 25.1169C341.74 19.7693 361.233 19.8416 400.221 19.9857L696.692 21.0815C737.687 21.2325 758.184 21.3089 776.23 27.2798C792.194 32.562 806.699 41.1538 818.774 52.4806C832.423 65.2849 841.676 82.8321 860.183 117.928L980.548 346.176C998.887 380.95 1008.06 398.337 1010.94 416.674C1013.49 432.897 1012.46 449.584 1007.94 465.636C1002.82 483.778 991.558 500.669 969.023 534.451L803.775 782.175C781.734 815.216 770.713 831.737 756.054 843.629C743.084 854.153 728.106 862.004 712.074 866.687C693.957 871.978 674.104 871.643 634.398 870.973L340.624 866.016L340.623 866.016C300.251 865.335 280.065 864.994 262.316 858.934C246.611 853.572 232.358 844.996 220.486 833.765C207.067 821.072 197.948 803.779 179.711 769.196Z" fill="{{branding.colors.primary}}"/>
                </svg>
                {%- auth0:widget -%}
            </div>
        </div>
    </div>
  </body>
</html>
```

## Explore Your Own Designs

By the end of this article, you can now design and customize signup and login experiences with Auth0 that are as beautiful and user-friendly as the rest of your application. With the power of custom templates, you can integrate your brand's color palette, unique fonts, and more. I'd love to see the unique and effective login experiences you create! Please share screenshots or links in the comments below.

Thanks for reading!

Building Beautiful Login Pages with Auth0

Calah Vargas

Calah Vargas is the Associate Manager of Product Led Growth, focusing on nonprofits, startups, and partnerships. She works on product marketing and customer marketing initiatives. Outside work, you can find her cooking, trying new restaurants, and traveling with friends and family.

Associate Manager, PLG

Upgrading made easy: from in-house authentication to modern login flows, flexible user profiles, and the convenience and security of passkey

Imagine you’re working on a monolithic application that includes a home-grown authentication system. Over the years, the authentication function has received upgrades here and there to improve security and to stay reasonably up-to-date in a changing world.

Sooner or later — perhaps triggered by considering different growth paths and how best to make use of developer time — you start to recognize that your in-house Identity stack is a limiting factor:

* Integrating with partners and other technology components requires custom work
* Maintenance obligations are distracting from work on your core app
* Meeting regulatory requirements for privacy is an ongoing challenge 
* Providing different access privileges to different types of end users is becoming more complicated than ever anticipated
* With every breach headline, you’re reminded of the constant need to strengthen security

Shopper Approved found themselves in a similar situation — in 2017, the company’s ambitions were outgrowing the home-grown Customer Identity capabilities of their monolithic PHP app.

With that realization, the search was for a third-party authentication solution.

# Why Shopper Approved chose Auth0 by Okta 

Since its launch in 2010, [Shopper Approved](https://www.shopperapproved.com/) has helped over 20,000 eCommerce brands — from mom-and-pop shops to global enterprises — generate more online trust, visibility, and conversions.

> “We knew we wanted to replace our login and authentication mechanism, and we needed a solution that would ‘tango’ with our [Laravel](https://laravel.com/) front-end templating engine,” Christopher Budge, Shopper Approved’s CTO recalled, “but we didn't know which direction we wanted to go in.”

<include src="QuoteCard" body="The Self-Service pricing was really attractive to us. The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While searching online for ideas and options, Budge came across Auth0 — and, in particular, the Self-Service plans.

> “The other providers that we found were prohibitively expensive for what was initially an experimental project, and not a lot of them had the adaptability that we needed to integrate into our existing application.”

The Self-Service option gave Budge and the wider team plenty of time to perform due diligence. “_We looked for a long time before ultimately deciding upon Auth0,_” he shared. “_The more I dug into it, the better it looked._”

The ability to explore the solution in a hands-on manner, without a commitment, helped the team to make an informed choice. Budge explained that:

<include src="QuoteCard" body="I got together with our technical lead and programming contractor, and they started playing with it — and then they said, 'Yeah, we think this is going to work." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

While every organization’s Identity journey is unique, here’s how Shopper Approved implemented Auth0.

## Migrating Users from the Legacy System to Auth0	

No matter how much preparation is done, a migration is always a nervy thing. As it turns out, those nerves were unnecessary — Shopper Approved’s migration from their legacy, home-grown authentication system to Auth0 went off without a hitch.

Budge recalled, “_We weren't sure how well our system would adapt to having its old authentication system ripped out and something new put in its place, but the migration actually exceeded expectations. Within 24 hours, we were able to ingest our entire user database into Auth0 and have them set up as users able to log in._”

However, migrating users was simply the foundation for modernizing the experience for Shopper Approved’s customers, with Budge adding, “_The universal login allows for such a smooth application login and flow. And our marketing team has really appreciated the customization and branding options that allow us to deliver a better customer experience._”

### Letting quickstarts guide the way

One of the first things Budge’s team did was explore Auth0’s step-by-step [quickstart guides](https://auth0.com/docs/quickstarts) to get a feel for the overall migration process.

“The quickstart guides were dead easy. Plus, between your host documentation and the notes in GitHub, it’s really, really easy as a developer to figure out ‘where am I and where do I need to go?’” and ‘What’s next?’”

![quickstarts](https://images.ctfassets.net/23aumh6u8s0i/58lZcrqemW0dCDEIrlLxef/fd17a831afcbbe647abd73d3420e9d95/01-migration.png)

### Leveraging SDKs

SDKs reduce the developer effort required to implement specific use cases, and Budge’s team found exactly what they needed among Auth0’s 40+ SDK libraries.

“Your SDKs are written really well, and your APIs are documented really well. So, code-wise, it’s extremely easy to interact with the platform — you can get going and don’t really have to think hard about it.”

![SDKs](https://images.ctfassets.net/23aumh6u8s0i/1cSZQDXlQ1VDHD7RFG71vu/6922a4a4409f3bab6453b7b48f12541e/02-migration.png)

## Building User Profiles

User data can come from many sources, including your own databases as well as social, legal, and enterprise identity providers. Some examples include Google, Facebook, Active Directory, and SAML.

In Shopper Approved’s case, there was an added complication — practically every user profile that had ever been created in their system still existed, and collectively, many of these profiles had inconsistent and incomplete data. But, perhaps counterintuitively, the upgrade actually presented an opportunity to clean up the user database. Budge’s migration script identified existing user records that were poorly formatted, allowing the team to quickly correct any issues — ultimately improving the overall structure of the company’s user data and laying a strong foundation for efficient scalability.

“The way your user profiles are set up — they’re just really easy to understand, manipulate, and customize. The data structure was easy to map to what we had and what we needed.” Maybe even more importantly, Budge recalled that “It just worked. When we were playing around with it, we saw that it does exactly what [your documentation](https://auth0.com/docs/manage-users/user-accounts/user-profiles) says it does.”

![User Profiles](https://images.ctfassets.net/23aumh6u8s0i/3EfvAVkkj9Ornz9JcTH5CJ/1783bd310eb0cd0722dbbe754aa606c4/03-migration.png)

## Innovating With Identity: Exploring Passkeys

The Identity domain is always evolving, with new specifications, standards, and [regulatory requirements](https://auth0.com/security) frequently appearing.

Unsurprisingly, one of the reasons why Budge was so eager to introduce a leading off-the-shelf solution was that it would allow the company to keep pace with these changes — while at the same time allowing the team to apply their finite resources on their core value proposition. In short, he knew that choosing Auth0 meant that Shopper Approved’s CIAM needs would be met today, tomorrow, and as far into the future as he could imagine.

Like many CTOs, Budge had closely been following [passkeys](https://learnpasskeys.io/) — FIDO credentials that are discoverable by browsers or housed within native applications to enable — and was excited by their potential to provide [a highly secure and very convenient user authentication experience](https://auth0.com/blog/webauthn-and-passkeys-for-developers/).

> “I’ve been watching passkeys for a long time, and — literally the day I got [the announcement that they were available](https://auth0.com/blog/activate-passkeys-let-users-log-in-without-password/) — I jumped right in. We really enjoyed rolling them out early to our organization, and we’ve had zero issues. And it’s great that we didn’t have to build passkey support ourselves!”
> _Christopher Budge_

![Passkeys](https://images.ctfassets.net/23aumh6u8s0i/3qOGVNCBexcnp5LqxkAcNB/7a0c5eaa7bdb2cd37987795f7a504712/passkeys.png)

## Enjoying Ongoing Value

Budge’s hopes for lower support and maintenance obligations have come to fruition. “We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken.”

Similarly, the upgraded security is evident. 

> “We've had many security researchers and penetration testers try to break in. Every time they run smack-dab into Auth0.”

<include src="QuoteCard" body="We have not had to spend a single development hour at all on user authentication and login — it's never failed, and it's never broken." name="Christopher Budge" title="CTO" team="" company="Shopper Approved" />

### Get started in minutes — for free — with no humans (other than yourself) required!

We’ve always tried to make things less complex for developers, which is why [our Self-Service plans](https://auth0.com/pricing) allow you to create a trial account with nothing more than an email address. During your 22-day trial period, you can create a simple app, configure its look and behavior, and explore the Auth0 solution in detail — giving you plenty of time to really get your hands dirty.

![Get started](https://images.ctfassets.net/23aumh6u8s0i/3s3e2u6XsF3BitzYgE3TpY/1097a71343e41a488444684c12c2c248/identity_journey.png)

Plus, anyone using our products can take advantage of resources including [quickstarts](https://auth0.com/docs/quickstarts), [40+ SDKs](https://auth0.com/docs/libraries), [detailed guides](https://developer.auth0.com/resources/guides/web-app/nextjs/saas-basic-authentication), and [extensive (but easy-to-follow) documentation](https://auth0.com/docs/articles) to help get started and implement a strong Customer Identity function.

In fact, with only a few lines of code, you can have Auth0 integrated into any app, written in any language, and in any framework.

[Try for free](https://auth0.com/signup?utm_source=whitepaper&utm_medium=auth0&utm_campaign=whyauth0) and see for yourself.


A Customer Identity Migration Journey

Emily Ann Clemons

Emily Ann Clemons is the Product Marketing Manager for Workflows, Okta’s automation and orchestration platform that allows anyone to build Identity-based experiences using out-of-the-box integrations and templates. Prior to Okta, Emily Ann worked at Salesforce on other no-code tooling. Emily Ann is a proud graduate of Auburn University and lives in New York City.

Product Marketing Manager, Workflows

What you need to build —and where you need to take your customers — depends on a multitude of factors, including what stack you decide to rest your engineering laurels on.

Going from an anonymous user to a personalized loyalty member journey can take a thousand steps.

With minimal tech investment but a big impact on security and user experience (UX), Okta Customer Identity Cloud has the necessary tools to take the guesswork out of building for common and unique use cases alike.

## What is an Action?

Actions let you customize authentication and extend Auth0's capabilities with custom logic. The Actions platform allows you to visually build custom workflows with drag-and-drop Action blocks for complete control.

Actions don't require any downloads or updates on your end. They’re written in Javascript and have 2,000,000 npm modules available to start building. You can test an Action before making it live and even roll back with versioning, which saves the headache of remediation and debugging. 

End users also benefit from Actions — with our extensibility platform, you can customize experiences designed to lower friction, making it seamless for customers to convert from anonymous to known users.

## Learn by Example: Actions Templates

To support engineers in understanding the power of Actions, we’ve created templates that teach you how to kickstart your understanding of this powerful extensibility layer and address the most common use cases you’ll probably want to solve. 

There are many templates to choose from, intended to bolster your security posture, increase conversions, and improve customer retention.

### Use cases

Actions templates are organized into different use case categories:

* **MFA**: create table stakes for your MFA implementation, and harness Machine Learning confidence scoring to implement your own adaptive MFA program
* **Enrich profile:** connect your upstream and downstream services with Auth0 as your unified source of truth for the user profile
* **Access control**: limit access to a select group of users and check important account and session information

We designed these use cases to help you get the most out of your Identity solution with Okta Customer Identity Cloud.

### Triggers

Templates provide you with sample code to get you started with different use cases that can be associated with the following triggers:

* Login
* Machine to Machine
* Pre-User Registration
* Post User Registration
* Post Change Password
* Send Phone Message
* Password Reset / Post Challenge

Multiple Actions can be associated with a single trigger, and you can customize templates to work for your own use cases and flows. 

## Migrate from Rules and Hooks or DIY Code

With Rules and Hooks being [deprecated by late 2024](https://auth0.com/blog/preparing-for-rules-and-hooks-end-of-life/), you can trust Actions templates to guide you through best practices that we’ve baked into the platform. Most Rules and Hooks properties have been moved or reshaped into Actions, so semantics are now clearer and more well-organized with new, consolidated ways of expressing the same or similar information.  

Actions streamlines your coding efforts with programming models closely aligned with the Auth0 management API and Auth0 platform.

The way the data is accessed in Actions promotes safe and efficient code, potentially saving you on costly calls to different APIs and running into rate limiting.

Actions templates teach you how to write your own custom code to save you time to ship.

We’ve covered our favorite Actions templates in the following implementation guides that only scratch the surface when it comes to Actions:

* [Adaptive MFA](https://www.okta.com/resources/whitepaper-make-your-mfa-adaptive-with-actions-templates/)
* [Flag sensitive transactions for step-up authentication](https://www.okta.com/resources/whitepaper-flag-sensitive-transactions-for-step-up-authentication/)
* [Collect FPD post-reg and post-login](https://www.okta.com/resources/whitepaper-connect-your-application-to-salesforce-with-first-party-data/)

Actions Template Implementation Guides: Introduction

Jefferson Haw

With over 10 years of IT industry experience, Jefferson is a principal solutions architect at Okta, the leading provider of identity and access management solutions. He specializes in designing and delivering end-to-end strategic industry solutions that leverage the power of identity to accelerate digital and security transformation projects for his customers. He works with a diverse range of industries, such as media, telco, FSI, QSR, retail, and education, across the APJ region.

Principal Solutions Architect

Leverage Optic ID with Passkeys for a passwordless login experience

## What is Apple Vision Pro

Two months into 2024, Apple finally released its new product, Apple Vision Pro. Apple [claims](https://www.apple.com/au/newsroom/2023/06/introducing-apple-vision-pro/) the Apple Vision Pro is **_“a revolutionary spatial computer that seamlessly blends digital content with the physical world while allowing users to stay present and connected to others.”_**

The release of Apple Vision Pro opens up the world of multiple possibilities in different industries. Retail, gaming, services, and hospitality industries could be the early adopters of this untapped market.

In this new world, every consumer will move to a hands-free, digitally connected world. The Apple Vision Pro also allows its users to do video passthrough, wherein consumers can roam around the real world wearing the headset and leverage its capabilities on the go.

![Apple Vision Pro](https://images.ctfassets.net/23aumh6u8s0i/WDoOkdjK7w2vY6BD5xbqb/cc7b8e8b79cc413132440b68194267ba/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

The most significant change for application developers and service providers to worry about is **the ability of their applications to continue identifying their consumers without relying on their end users to ‘air-type’ their credentials**, which could lead to a poor user experience.

![Apple Vision Pro](https://images.ctfassets.net/23aumh6u8s0i/5dHPtNoIzDwA8UKqWhyIZX/6afdcdf3ff14e11dbb953c363123054c/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

The gap and opportunity above allowed Apple to rethink the whole experience with Apple Vision Pro. Apple came out with a new technology called [Optic ID](https://support.apple.com/en-us/HT214051). As per Apple, **_“In the same way that Touch ID revolutionized Authentication using a fingerprint and Face ID revolutionized Authentication using facial recognition, Optic ID revolutionizes Authentication using iris recognition. Optic ID provides intuitive and secure Authentication that uses the uniqueness of your iris, which is made possible by Apple Vision Pro’s high-performance eye-tracking system of LEDs and infrared cameras.”_**

Optic ID works similarly to FaceID or TouchID, and the great thing about it is that it leverages [Webauthn](https://auth0.com/blog/webauthn-a-short-introduction/) as its underlying technology. This mechanism allows developers and service providers to use ‘passkeys’ to identify their users in a passwordless manner. Using passkeys removes the need for users to ‘air-type’ their credentials every time they sign in and purely leverage Optic ID as the mode of identification.

## Passkeys

Auth0 by Okta has also formally released support on [passkeys](https://www.okta.com/blog/2024/02/passkeys-are-generally-available/) to the general public to support the passwordless revolution. Auth0’s support for passkeys helps developers and service providers support their passwordless movement in a simple, easy, and efficient manner.

<include src="LearnPasskeysCTA"/>

Turning on passkey support in Auth0 is easy, whereas administrators only need to toggle on a switch within the Auth0 management console. To do this, Auth0 administrators must log into the Auth0 Management console.

![Auth0 Management](https://images.ctfassets.net/23aumh6u8s0i/uZIu0fXy8OPNPaysoydqF/8b473005600d38b79b97f3c68185f147/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

Once inside the Auth0 Management console, navigate to Authentication and select Database. You should be redirected to the Database Connections view. Select the Database in which you wish to enable passkeys.

![Database connections](https://images.ctfassets.net/23aumh6u8s0i/6VwZONnH1ByDkO1AkUT3n9/49dd1f917301e268bfc6c42fdbfb8c13/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

For this example, I’m using the Username-Password-Authentication database. Select and click the Username-Password-Authentication link. You should be redirected to the Username-Password-Authentication Database view.

![Username-Password-Authentication](https://images.ctfassets.net/23aumh6u8s0i/3MslafSaz5ruWO379N5cue/7bef2b78cd9880248b3031b3336404f1/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

Select and click the Authentication Methods tab. You should be redirected to the Authentication Methods page.

![Authentication Methods tab](https://images.ctfassets.net/23aumh6u8s0i/3orZ7MHnZfm4bQXyte3zlu/f79ef48782854a4eba251dad24aeae40/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

By default, passkeys will be disabled. Click the toggle to enable passkeys.

![passkeys](https://images.ctfassets.net/23aumh6u8s0i/6OmC9XBbCdSzznCus1pfZM/13950b7b69233ebc9bcf0b6738cc7276/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

Once you’ve turned it on, you should automatically be able to see your login page to reflect the changes. You’ll now have a “Continue with a passkey” button in your login box.

![login page](https://images.ctfassets.net/23aumh6u8s0i/5q7c90dDCl2cFe9JY5U7Ly/1f1b763694d77a02e9e3ee74a4658960/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

The great thing about this new capability is that it also handles the creation of a passkey if the user hasn’t registered one yet.

![passkey](https://images.ctfassets.net/23aumh6u8s0i/3vZR49dKpZ5qGZho6oQzGT/1ead631184219967ae327a22947ba895/Uploaded_from_Using_Passkeys_for_a_Seamless_Login_Experience_in_the_Apple_Vision_Pro)

You might be wondering what the experience of Auth0 passkey support with Apple Vision’s Pro would be like. The experience would be:

1. The user opens a native application built and designed in the Apple Vision Pro platform.
2. To start the immersive shopping experience, the user must log in first. The user clicks the start shopping button within the native application.
3. Clicking the start shopping button will open a web view that will redirect to the Auth0 Universal Login page.
4. Once the Auth0 Universal Login page loads successfully, rather than having the user air type their credentials to log in, they can simply click the button labeled ‘Continue with a passkey.’
5. After clicking the button, the user will be asked to verify themselves using the ‘optic id’ capability as a sign-in method.
6. If the Optic ID verification is successful, the user will be successfully authenticated and login to the application

A demonstration of the experience is shown in the video below.

<AmpContent>
<amp-youtube
    data-videoid="a9mVCEfg6ts"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>
<NonAmpContent>
<div class='embed-container' style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;"><iframe style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;" src='https://www.youtube.com/embed/a9mVCEfg6ts' frameborder='0' allowfullscreen></iframe></div>
</NonAmpContent>

<br>

I hope you find this post insightful on how you can enable passkeys via Auth0 by Okta so that you can deliver a seamless user experience in a passwordless manner, whether through your standard laptop or using Apple’s latest innovation, the Apple Vision Pro.

Read more on how you can configure [passkeys in Auth0](https://auth0.com/docs/authenticate/database-connections/passkeys).

Using Passkeys for a Seamless Login Experience in the Apple Vision Pro

michael-swanson

I live in Austin, TX with my wife, Anneke, and our two kiddos, Ilya (5) and Everett (2). I am a native Texan but lived in multiple places across the southern US as a kid. I have family in Houston TX and Midland TX that we visit on a regular basis. Prior to joining Okta, I worked with early stage startups as a hands-on Product Manager, team lead, and product designer, while also writing (mostly frontend) code. 
<br>

When I am not working you can usually find me chasing my kids around, reading sci-fi or fantasy novels, or playing needlessly complex strategy board games with friends. I am also a huge Star Wars fan and am always down to talk about the latest Star Wars movies, TV, and/or books. Additionally, Anneke and I love to travel and have been all over the world together. Much of our travel focuses on getting out of the Texas heat, tasting and learning about wine, and sampling the amazing food we find along the way!


Senior Product Manager

Michael Swanson

Businesses using Auth0 by Okta’s Universal Login, can leverage a pro-code option to customize signup and login flows to address unique needs.

Every company has unique user registration and login requirements. For example, needing to capture a first and a last name during signup or requiring users to agree to terms and conditions before they can create an account. 

To meet those specific business needs and use cases, we have introduced pro-code customizations for signup and login to the Universal Login experience. This capability is available to customers on our Enterprise and Professional plans.

Using this capability, customers can insert additional form fields and custom content into the signup and login screens and include client and server-side validations to ensure that required data, such as TOS acceptance, are completed and validated before completing the authentication process. 

Use cases include:

* Adding new fields to collect necessary customer data (name, phone number, email, preferences, consent, etc.)
* Adding new form elements for presenting and capturing TOS/privacy policy and opt-in before signup
* Adding custom content such as URLs, images, or marketing information
* Localizing custom elements in different languages

### Getting started

The new [Partials API](https://auth0.com/docs/api/management/v2/prompts/get-partials) allow developers to insert custom HTML, CSS, and Javascript into the Signup and Login screens. Developers can insert new form elements and custom content, perform asynchronous client-side validation via Javascript, and leverage [Liquid syntax](https://github.com/Shopify/liquid/wiki/Liquid-for-Designers) to perform conditional logic and insert dynamic variables. Here is an example of inserting custom code into the Signup screen:

```js
# eg: PUT /api/v2/prompts/signup/partials

# Request Body
{
  "signup": {
    "form-content-start": "<div class='ulp-field'><label for='first-name'>Full Name</label><input type='text' name='ulp-full-name' id='full-name'></div>",
    "form-content-end": "<div class='ulp-field'><input type='checkbox' name='ulp-terms-of-service' id='terms-of-service'><label for='terms-of-service'>I agree to the <a href='https://my.app/terms' target='_blank'>Terms of service</a></label></div>",
  }
}

```

Once the user submits the Signup form customers will have access to the data via Actions. Here is an example of saving user provided custom data to the user_metada for the end user

```js
/**
* Given this code in the signup form:
* <div class="ulp-field">
*   <label for="full-name">Full Name</label>
*   <input type="text" name="ulp-full-name" id="full-name">
* </div>
* <div class="ulp-field">
*   <label for="terms-of-service">
*     I agree to the <a href='https://my.app/terms' target='_blank'>Terms of service</a>
*   </label>
*   <input type='checkbox' name='ulp-terms-of-service' id='terms-of-service'>
* </div>
**/

exports.onExecutePreUserRegistration = async (event, api) => {
  const fullName = event.request.body['ulp-full-name'];
  const terms = event.request.body['ulp-terms-of-service'];
  
  if(!fullName) {
    api.validation.error("invalid_payload", "Missing Name");
    return;
  }
  
  if(!terms) {
    api.validation.error("invalid_payload", "Acceptance is Required");
    return; 
  }

  api.user.setUserMetadata("fullName", fullName);
  api.user.setUserMetadata("termsAcceptance", terms);
};

```

To learn more about how Signup and Login Prompt Customizations works and to view tutorials and examples, refer to the public documentation.

* Custom-facing Documentation: [Customize Signup and Login Prompts](https://auth0.com/docs/customize/universal-login-pages/customize-signup-and-login-prompts)
* Management API Documentation: [Auth0 Management API v2: Manage Partials](https://auth0.com/docs/api/management/v2/prompts/get-partials)

Customizations for Signup and Login are Generally Available

Customers and trial customers on Enterprise and Professional plans can now customize signup and login flows to address unique needs.

Each company has unique user registration and login requirements, for example, needing to capture a first and last name during signup or requiring users to agree to terms and conditions before they can create an account. 

In order to meet specific business needs and use cases, companies often have to build and maintain different experiences – hosted pages and sites – within their account registration and login flow(s). Unfortunately, this approach slows down the time to market by introducing separate code bases that require localization and maintenance while also creating an inconsistent customer experience.

To solve this problem, we have introduced custom prompts for signing up and logging in to Universal Login. This capability is now open for early access (EA) and available to our customers and trial customers on Enterprise and Professional plans. 

## Addressing Unique Use Cases

With custom prompts for signup and login, our customers can customize and add new fields to existing signup and login prompts; this includes client and server-side validation to ensure that required data and requirements, such as Terms of Service (TOS) acceptance, are completed and validated before completing the signup or login process. 

Leveraging Universal Login and our extensibility framework, our customers can tailor these two experiences to address data capture, security, regulatory, and customer experience requirements. Use cases included:

- Add new fields in order to collect necessary customer data (name, phone number, email, preferences, consent, etc.) 
- Add new form elements for presenting and capturing TOS/privacy policy and opt-in before sign up
- Add custom content such as URLs, images, marketing information
- Localize custom text in different languages

## Getting Started

During open early access, this feature will be automatically available to all of our Professional and Enterprise customers and trial accounts. To get started, please check out our documentation [here](https://auth0.com/docs/customize/universal-login-pages/customize-signup-and-login-prompts). If you have any questions, please reach out to your Account Executive.  

Before closing, I want to give a shout-out to our customers who provided feedback during the limited EA. We had over 75 customers join and received invaluable feedback. This underscores the importance of this capability, which we’ll continue to evolve and shape based on customer feedback, so please let us know how it goes.  


_Any products, features, or functionality referenced in this material that are not currently generally available may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation, or promise to deliver any product, feature, or functionality, and you should not rely on them to make your purchase decisions._


Customizations for Sign up and Login Now in Open Early Access

Detect hackers with Auth0 Actions and special accounts designed to catch them in the act.

Use Honeytokens and Auth0 Actions to Catch Malicious User Logins

sam-yapkowitz

I began my career in enterprise software development and got exposure to lots of different frameworks and methodologies. I quickly realized my passion was in the architecture and design of solutions to unique problems. I now get to use these skills to help my customers build high-quality experiences using Okta. When not at work you can find me on the golf course, playing Rocket League or watching football with my friends.

Specialist Solutions Engineer

Sam Yapkowitz

Learn how to perform A/B testing on the Universal Login page using Liquid templates and custom parameters.

There is no way to natively A/B test the Universal Login as of today. But, it can be achieved with the use of the [Liquid](https://shopify.github.io/liquid/basics/introduction/) templates that power the Universal Login, custom parameters passed from the client side, and an A/B testing platform such as [Split.io](http://split.io/), [Google Optimize](https://marketingplatform.google.com/about/optimize/), or [LaunchDarkly](https://launchdarkly.com/).  A/B testing, also known as split testing, refers to a randomized experimentation process wherein two or more versions of a variable (web page, page element, etc.) are shown to different segments of website visitors at the same time to determine which version leaves the maximum impact and drives business metrics.

## What Is the Universal Login?

Auth0 Universal Login (UL) defines your login flow, which is the key feature of an authorization server. Whenever a user needs to prove their identity, your applications redirect to Universal Login, and then Auth0 will do what is needed to guarantee the user's identity.

When using Universal Login, you don't have to do any integration work to handle different methods of authentication. You can start off using a simple username and password, and then add other features, such as social login and multi-factor authentication (MFA).

Configuring Universal Login is dynamic (and does not require application-level changes) because all functionality is driven by the web pages served by the centralized Authentication Server. Your applications benefit from any improvements Auth0 makes in the login flow without the need for you to change your code.

You can create a consistent, branded login experience by customizing the login page appearance and behavior from the Auth0 Dashboard. For advanced use cases, you can even change the code of each page.

To learn more about the differences between Universal Login and embedded login, read [Centralized Universal Login vs. Embedded Login](https://auth0.com/docs/authenticate/login/universal-vs-embedded-login).

## Universal Login Liquid Templates

The UL can be modified through the use of Liquid [templates](https://auth0.com/docs/customize/universal-login-pages/universal-login-page-templates).  To work with these Liquid templates, you will need to configure a [Custom Domain](https://auth0.com/docs/customize/custom-domains). These templates allow you to define the HTML, CSS, and JS that are shipped to the client when making an `authorize` request. These Liquid templates allow you to run conditional logic based on the Liquid syntax. This functionality allows you to provide a unique UX based on things such as application, organization, tenant, locale, and specific screen. There is the ability to pass specific query parameters during an `authorize` request that can be accessed inside the Liquid template syntax for even further customization options. These parameters must be prefixed with `ext-` to be honored by the UL. These can be accessed through `transaction.params.ext-{param}`. With these parameters, we can now specify different versions of the UL to render for a user. Here is a Liquid template example of conditionally branding the UL based on one of the custom query parameters. This example leverages the param `ext-alt-brand`:

```html
<!DOCTYPE html>
<html lang="{{locale}}">

  <head>
    <title>Welcome to {{ application.name }} </title>
    {%- auth0:head -%}
    <style>
      {% if transaction.params.ext-alt-brand == "portal_0" %}
      body {
        background-image: radial-gradient(blue, rgb(200, 200, 200));
      }
      #custom-prompt-logo {
        background-image: url('https://banner2.cleanpng.com/20180328/roq/kisspng-circle-logo-symbol-font-templates-5abbf957bfda53.1977074015222685037859.jpg');
      }
      {% elsif transaction.params.ext-alt-brand == "portal_1" %}
      body {
        background-image: url("https://images.unsplash.com/photo-1592450865877-e3a318ec3522?ixlib=rb-1.2.1&auto=format&fit=crop&w=2255&q=80");
        background-size: cover;
        background-position: center;
        background-repeat: no-repeat;
      }
      #custom-prompt-logo {
      background-image: url('https://bootstraplogos.com/wp-content/uploads/edd/2017/11/logo-51.png');
      }
      .prompt-wrapper {
        position: relative;
        display: flex;
        align-items: center;
        width: 480px;
        height: 100%;
        justify-content: center;
        background-color: rgb(247, 198, 233);
      }
      {% else %}
      body {
        background: linear-gradient(-45deg, #ff44dd, #3885ff, #3ec6eb, #1bc99f);
        background-size: 100% 100%;
      }
      #custom-prompt-logo {
        background-image: url('https://cdn.auth0.com/blog/auth0rta/theme/logos/auth0-logo-black.png');
      }
      {% endif %}
      {% if organization != null && organization != undefined %}
        #custom-prompt-logo {
            background-image: url({{ organization.metadata.logo_url }});
        }
        body {
            background: linear-gradient({{ organization.metadata.linear_gradient }})
        }
      {% endif %}

  </style>
  </head>
  <body class="_widget-auto-layout _use-custom-prompt-logo">
      <div class="prompt-wrapper">
        {%- auth0:widget -%}
      </div>
  </body>
</html>
```

When the value of the param `ext-alt-brand` is `portal_0`, the following version of the login page (say, version A) will be shown:

![Universal Login test page version A](https://images.ctfassets.net/23aumh6u8s0i/HaEPIJiEdF8m9l9XI96i2/a2b427c463052ef25e8e1395d83497ab/universal-login-test-a.png)

When the value of the param `ext-alt-brand` is `portal_1`, version B of the login page is shown:

![Universal Login test page version B](https://images.ctfassets.net/23aumh6u8s0i/5hWtq9COZWNfSAXgvzwB4r/ad29b45a10bd7d3f3843f87c8c93eeba/universal-login-test-b.png)

> Note: You can see the domain and application are the same, yet we have a unique UX for an A/B test.

## Client-Side Implementation

There are many ways to accomplish an A/B test with the Universal Login now that we understand how to render separate versions of the UX. A traditional A/B test will have equal weights between all of the options, and upon a user entering one of these flows, the first step would be to check the browser for a cookie indicating whether a particular user has entered into the experiment already.

If the user is new, they will be assigned one of the pathways for the experiment and then be delivered the content for the item. If a user has previously entered the experiment, we can examine their cookie to determine which pathway they belong to and continue delivering them that same content to provide a consistent UX for the lifetime of the experiment.

This can be implemented manually, but many providers offer this service OOTB, such as Split and LaunchDarkly, to help you make this piece more flexible as you run more experiments or implement feature flagging from a deployment perspective. For this writeup, I have built out examples leveraging both Split and Google Optimize.

To put the final piece in place, my application is built with Next.JS and deployed on Vercel to take advantage of their [Edge Middleware](https://vercel.com/docs/concepts/functions/edge-middleware) capability. This piece is purely preference, and is very dependent on your current implementation of CIC. The Edge Middleware functionality on Vercel allows you to intercept requests on the edge and rewrite URLs extremely quickly. This allows you to decouple the A/B test from your client-side authentication logic. For instance, any place in my application can continue to leverage the same login route without needing more logic to be added. The Edge Middleware then interfaces with my A/B provider to read/write cookies as well as modify the login route to supply the proper parameter during the `authorize` request. You can view the source code for the [Google Optimize](https://github.com/samyap4/auth0-ab-testing-optimize) example and the [Split](https://github.com/samyap4/auth0-ab-testing-split) example on my GitHub.

## Live Examples

Here are snippets of the live examples in action on [Split](https://auth0-ab-testing-split.vercel.app/). The cookie being set here is called `flag-universal_login`. This is version A in action:

<AmpContent>
<amp-youtube
    data-videoid="dnjnnIVDp-Q"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div
  class='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/dnjnnIVDp-Q'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

Here is version B in action:

<AmpContent>
<amp-youtube
    data-videoid="zgj5SpiRuVo"
    layout="responsive"
    width="480" height="270">
</amp-youtube>
</AmpContent>

<NonAmpContent>
<div
  class='embed-container'
  style="position: relative; padding-bottom: 56.25%; height: 0; overflow: hidden; max-width: 100%;margin-bottom:40px;">
    <iframe
      style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
      src='https://www.youtube.com/embed/zgj5SpiRuVo'
      frameborder='0' allowfullscreen>
    </iframe>
</div>
</NonAmpContent>

You can see the application is the same, and I can generate a different UX based on the cookie being set by my [Split.io](http://split.io/) configuration.

## Implementing Analytics

Now that we have demonstrated how to deliver different experiences to different users, the final step of the A/B testing journey will be to start gathering metrics about how users are interacting with your content. We already discussed that we can leverage the templates to bring in custom scripts to your Universal Login screens. You can use whatever service you like for tag management, such as [Google Tag Manager](https://marketingplatform.google.com/about/tag-manager/).

## Conclusion

At Auth0, we aim to provide a high-quality service and developer experience for our customers. The first interaction with your customers is often times a login screen, so we understand how important it is for the user experience to be top-notch. With our hosted Universal Login, we take away the burden of deploying and maintaining these highly secure workflows. With the capabilities of our templates outlined in this post, we are able to help your teams iterate more quickly and customize the experience to be sticky for your brand and ultimately help your business grow.


Universal Login A/B Testing

Auth0 by Okta now supports passkeys! Here’s how you activate them so your users can enjoy passwordless login.

## Passkeys Are Now Available in Auth0 by Okta!

Passkeys are a replacement for passwords, and they’re now a feature in Auth0! Your users can enjoy the convenience and enhanced security that passkeys provide.

If you’d like to find out more about what passkeys are, what the user experience is like, and how they work, take a look at this article on the Okta blog: [*_Adding Passkeys to Your Applications with Okta Customer Identity Cloud Powered by Auth0_*](https://www.okta.com/blog/2023/10/adding-passkeys-to-your-apps-with-okta-cic-powered-by-auth0/). It will provide you with plenty of background information about this new feature.

If you want to activate passkeys for your users, read on! You’ll be pleased that the process takes very few steps.

<include src="LearnPasskeysCTA"/>

## Activating Passkeys

Passkeys are available as a feature on all Auth0 plans — even the free ones! This means that if you want to familiarize yourself with passkeys and their user experience, you can <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">set up a free tenant and add passkey-enabled authentication to your applications at no cost</a>.

### Good news for developers: you don’t have to update any code!

![Developer in chair with a laptop in their lap, arms raised in victory.](https://images.ctfassets.net/23aumh6u8s0i/2HWOHOwXs1jU1XmXWPAJJP/91161bac9d396cf9b57d0a7d281593e1/cheering_developer.png)

You don’t have to change any of your application code to support passkeys. The code that displays the Universal Login box with the email and password displays the new version with the _Continue with a passkey_ button once you enable passkeys in your tenant.

### How to activate passkeys

To enable passkeys for your users, sign into the Auth0 Dashboard, and if necessary, select a tenant.

In the left column menu, select _Authentication_ → _Database_. You will be taken to the _Database Connections_ page:

![Database Connections page](https://images.ctfassets.net/23aumh6u8s0i/3XfCfsP4PJcdX6M2Q8vqFP/e13422d9053117bf7305e6913379ee82/01.png)

Remember that with passkeys, the authentication server stores the users’ public keys. This means that in order to enable passkeys, user information must be stored in an Auth0 database. **You cannot use a custom database if you want users to sign in with passkeys.**

Choose an existing Customer Identity Cloud database from the list or create a new one by clicking the _+ Create DB Connection_ button and then choose that database. In this example, we’ll enable passkeys on the default _Username-Password-Authentication_ database connection.

You should now be on the Settings tab of the database connection:

![Settings page of the Username-Password-Authentication database connection](https://images.ctfassets.net/23aumh6u8s0i/64SMnTqwOg5tBH0ySuvXIZ/11030b48bbaa9a315262c69a7a509849/02.png)

Click the _Authentication Methods_ tab. This is where you activate passkeys:

![Authentication Methods tab, with Passkey switch in the “off“ position](https://images.ctfassets.net/23aumh6u8s0i/7fVIRsMNCunbLv6R9Fclig/4695bcd2c8e72a803306127ec71f0da3/03.png)

Turn on the _Passkey_ switch. This will activate passkeys for the tenant’s users.

Depending on your current database setup, you might need to change some settings before you can enable passkeys. You’ll know this is the case if you click the _Passkey_ switch and see a pop-up like this:

![Pop-up showing missing passkey prerequisites](https://images.ctfassets.net/23aumh6u8s0i/4ofnZJpwGuWaNvSBGDxbPa/977ba453f6dab114a2eec4667b861b5e/04.png)

Click the link for any item marked _PENDING_ and make the required changes. For example, if “New Universal Login Experience must be enabled:” is _PENDING_, click that link to go to the login experience page and enable the New Universal Login.

Here are all the required configurations for passkeys:

* Enable these features:
	* **Identifier First login flow.** The _Identifier First_ login flow presents the user with a screen where they enter their identifier, followed by another step where the user provides proof of their identity, such as a password or confirmation from a face or fingerprint recognition system. It differs from the _Identifier + Password_ login flow, which presents the user with a single screen to enter both their email and password.
	* **New Universal Login Experience.** The New Universal Login Experience provides many improvements over the Classic Universal Login Experience, including support for the W3C/FIDO Web Authentication API, which is necessary for passkeys.
* Disable these features:
	* **Custom Login Page.** Currently, the login flow for passkeys does not support custom login pages.
	* **Requires username.** With passkeys, there is no need for an additional text field for the user to enter a username.
	* **Use my own database.** Passkeys require a specific database setup, so only the Customer Identity Cloud database is allowed when passkeys are enabled.

Once you’ve met all the prerequisites for passkeys, you can enable them. The page should look like this:

![Authentication Methods tab, with Passkey switch in the “on“ position](https://images.ctfassets.net/23aumh6u8s0i/Qlr00CvgsFGd46cOZR9or/7b2e1170a6a09fab9d24ed28e14db36a/05.png)

You can now configure the settings for passkeys. Do this by clicking the _Configure_ link for the _Passkey_ item. This will take you to the _Passkey Policy_ tab of the _Policies_ page for the database connection:

![Passkey Policy tab of Policies page](https://images.ctfassets.net/23aumh6u8s0i/643sxiccQjpWdUsBvL528s/3df48433375f1a95fce38f26c2d043e2/06.png)

Let’s take a closer look at each of the settings areas on this page.

The first section is the _Passkey Challenge_ section, which defines how Universal Login presents passkey options to the user:

![Passkey Challenge section](https://images.ctfassets.net/23aumh6u8s0i/2uTtiGuRmEJuejdOR6SPSd/7614660c58cef4565af973f121348bed/07.png)

The default selection, _Both_, results in a Universal Login box that looks like this:


<img src="https://images.ctfassets.net/23aumh6u8s0i/3AO5dXLKgt0kb4lscxD0Sr/abbe5b17cfc5576639e1070ea1589557/7a.png" alt="Universal Login box featuring both email address text field and “Continue with a passkey” button" width="500"><br>


This version of the Universal Login box provides two options for logging in with a passkey. First, there’s the very obvious _Continue with a passkey_ button at the bottom, which presents a list of passkey options when pressed.

There’s also the less obvious autofill. It appears when you click on the _Email address_ field, also providing passkey options:

<img src="https://images.ctfassets.net/23aumh6u8s0i/5RDJGPagC2loJtpOqxh4IA/278ef844d3768669badd009770cacebc/7b.png" alt="Universal Login box with a pop-up menu appearing beside the Email address text field" width="500"><br>

This is where the “discoverable” part of passkeys comes in. The user doesn’t have to type in their email address to log in because the browser is able to discover this information.

Since passkeys will be new to most users, we recommend providing users with as many options as possible by selecting the _Both_ option.

The next section contains the enrollment controls:

![Progressive Enrollment and Local Enrollment sections](https://images.ctfassets.net/23aumh6u8s0i/1CzIy25CTpwJczGVjD3fuO/3a41e2cce254ea1b864ef1a9db0f55b5/8.png)

We recommend that you turn on both _Progressive Enrollment_ and _Local Enrollment_, as they make for a better user experience. This is especially true for the _Local Enrollment_ option, which lets users create a new passkey on their local device.

## Take Passkeys for a Test Run

Now that you’ve enabled passkeys, it’s time to try them out. Click on _Getting Started_ in the left column menu, then click the _Try it out_ link in the _Try your Login box_ section:

![The Getting Started page](https://images.ctfassets.net/23aumh6u8s0i/6xIukz0MFdFz2qXLu2Vhvw/5e617d07eedb8067ff7f14760d06fde2/09.png)

You’ll see the Universal Login box:

<img src="https://images.ctfassets.net/23aumh6u8s0i/3AO5dXLKgt0kb4lscxD0Sr/abbe5b17cfc5576639e1070ea1589557/7a.png" alt="Universal Login box featuring both email address text field and “Continue with a passkey” button" width="500"><br>

Create a new account by clicking the login box’s _Sign up_ link. You’ll see this:

<img src="https://images.ctfassets.net/23aumh6u8s0i/72c8onNnTqteldYZyVSWvo/260381b65f9b03cd128639d07b4a3e01/10.png" alt="The “Create Your Account” window” button" width="500"><br>

Enter an email address into the field and click the _Continue_ button. You’ll be given the option to create a passkey:

<img src="https://images.ctfassets.net/23aumh6u8s0i/10NFQPGZWt0J812WYRXmBh/55f1ed8742ab35d711c315928793aa89/11.png" alt="Create a passkey for All Applications on this device" width="500"><br>

Click the _Create a passkey_ button. You’ll see this pop-up:

![The “Create a passkey” pop-up](https://images.ctfassets.net/23aumh6u8s0i/3fCLK6elDLVoKzGZVG02Pa/e942165fe827e794b21c16b84cc64293/12.png)

Select the _This device_ option. The pop-up will be replaced with this:

![The follow-up “Create a passkey” pop-up](https://images.ctfassets.net/23aumh6u8s0i/VGmCSE5HBr7xCb2j4xet0/29469f0cbb14a88e441d2be9622921fc/13.png)

Click _Continue_ to create a passkey on your computer.  You’ll then be asked to verify your identity with your computer:

![“Google Chrome is trying to verify your identity” pop-up](https://images.ctfassets.net/23aumh6u8s0i/2fj9aoDANJQnlmkdERZ8VY/0197f8812ddcb65110081b9556e9b032/14.png)

Once you’ve authenticated yourself, you’ll see this sign of success:

![The Deashboard’s “It Works!” screen](https://images.ctfassets.net/23aumh6u8s0i/1cdCf7Oq00Q7XvDsbDnFb4/41acb1dfd02feda06a42e446ca3b6a34/15.png)

Congratulations! You’ve successfully enabled passkeys on your tenant!

Try creating passkeys using your tenant’s applications and then logging in. Here’s one of my mobile apps authenticating against my passkey-enabled tenant:

![Universal Login screen with passkeys activated, as seen on an iPhone 14](https://images.ctfassets.net/23aumh6u8s0i/1lMA2ZcOHf9etfLx24v3au/23dda036a2aa52a0d882332a5e59e12a/16.png)

## Conclusion

Activate passkeys now and see how you can give your users a more convenient, more secure login experience!

* If you’re new to Okta Customer Identity Cloud Powered by Auth0, <a href="https://a0.to/blog_signup" data-amp-replace="CLIENT_ID" data-amp-addparams="anonId=CLIENT_ID(cid-scope-cookie-fallback-name)">sign up for a free trial account!</a>
* If you already have an account, you’ll want to look at our [passkeys documentation](https://auth0.com/docs/authenticate/database-connections/passkeys).
* Be sure to read the companion article to this piece, [*_Adding Passkeys to Your Applications with Okta Customer Identity Cloud Powered by Auth0_*](https://www.okta.com/blog/2023/10/adding-passkeys-to-your-apps-with-okta-cic-powered-by-auth0/)!


Activate Passkeys and Let Your Users Log in without a Password

Catherine Razeto

Catherine Razeto is a Staff Data Scientist on the Machine Learning team for Okta's Customer Identity products. She focuses on developing threat detection models to secure our customers' applications. She led the development of the machine learning engine for the Bot Detection security feature. She is interested in classification problems, anomaly detection and fraud detection at-scale.

Staff Data Scientist

The aggregated score indicates the level of bot activity seen across all CIAM customer login flows

From online retail to social media — and everything in between — bots are (one of the reasons) why we can’t have nice things. As we examine in detail in our[ State of Secure Identity Report](https://auth0.com/resources/whitepapers/2022-state-of-secure-identity-report), these digital automatons plague Identity flows at all parts of the user journey:

* Fake signups defraud registration forms and pollute customer intelligence systems;
* Brute force attacks use breached passwords in account takeover (ATO) attacks; and
* Malicious bots burden app owners with scams and spam, degrading the user experience.

Consumer-facing apps, in particular, must identify and filter out bots as part of their security and growth objectives — and since day one, Auth0 has devoted considerable effort to helping our customers do just that.

## Bot or Not?

As a vital part of the[ Attack Protection](https://auth0.com/docs/secure/attack-protection) add-on in the[ Okta Customer Identity Cloud](https://www.okta.com/customer-identity/), our[ Bot Detection](https://auth0.com/docs/secure/attack-protection/bot-detection) feature mitigates scripted attacks against native applications, passwordless flows, and custom login pages.

By correlating a variety of data sources — like past events associated with an IP address, recent login history, IP reputation data, and an assortment of other factors — we can detect when an Identity request is likely to be coming from a bot. When the Bot Detection feature detects bot or scripted login requests, it triggers a CAPTCHA step in the login flow.

Over the years, we’ve continually refined our bot detection capabilities: today’s version employs a machine learning (ML) model that ingests 60+ inputs — and when we introduced this new system last year, it[ reduced bot attacks by 79%](https://auth0.com/blog/auth0-bot-detection-reduces-bot-attacks-by-79/) above and beyond its precursor.

Importantly, the improved defensive capabilities were achieved without the expense of user friction: even during attacks, fewer than 1% of challenges are shown to legitimate human users.

## Building on Bot Detection: The Identity Threat Level (ITL)

Being at the ‘front door’ of applications with a Customer Identity and Access Management (CIAM) solution that secures billions of login transactions per month, Auth0 has a unique vantage point from which to monitor Identity threats.

This powerful perspective was the genesis of the Identity Threat Level (ITL), a score from 0 to 10 that indicates the level of bot activity targeting CIAM systems: a score of 0 means there’s practically no bot activity to speak of, while a score of 10 means almost all traffic is attributable to bots.

By aggregating (anonymously, of course!) observations across our customer base, we can calculate an ITL for different industries and geographies, with the option of introducing additional slicing and dicing on other common attributes.

Tracking historical trends and daily shifts has the potential to inform of elevated risks to CIAM login and sign-up flows, enabling app providers to increase their own monitoring, proactively tighten thresholds, implement additional defenses — or respond in any other way they see fit.


<div class="alert alert-info alert-icon">
  <i class="icon-budicon-487"></i>
  <strong>Behind the scenes</strong><br> 
Here's a simplified overview of how an ITL is calculated.<br>
Each day, the ITL instrumentation analyzes traffic samples that cover all industries and geographies and includes customers of all sizes.
By cross-referencing the samples against our Bot Detection capabilities, we're able to determine with high accuracy what proportion of those Identity flows are associated with bots.
Finally, for each dimension or combination of dimensions (e.g., Financial Services in North America), we calculate the ITL.<br>
The ITL is based on traffic from Okta's Customer Identity Cloud customers; we believe it's reasonable to conclude that organizations that aren't customers will experience similar threats, but we cannot and do not assert that this is definitely the case.<br> 
</div>

## Sneak-Peak Observations

While future posts will explore the ITL in greater detail, including diving into Identity trends and perhaps even specific attack campaigns, in this post, we’ll stick to some high-level observations.

For example, consider the chart below, which shows the ITL for the Travel/Transportation industry, across all regions, from January 1st, 2023, through April 1st, 2023.

Just from a quick visual examination, we can see that so far in 2023, this ITL fluctuates up and down around an average of about 5.5, with the peaks corresponding to weekends (some industries exhibit this weekday/weekend pattern, and others don’t).

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/4ahrXj9vXgxuQnLrwXlU6w/b5df3271d0dee7ac8a87819a8247e38f/Battling_Bots_01.png)

Next, let’s use the ITL to see how the threat of bots varies across industries. In the chart below, we’ve zoomed out to a weekly view to more clearly showcase the general trends in Financial Services, Retail/eCommerce, and Software/SaaS/Tech.

We can see that of the three industries, Retail/eCommerce has experienced the highest peak ITL (nearly 8) and has had an average score of around 6. During the same period, Financial Services peaked at an ITL of 7 but has generally trended downward, while Software/SaaS/Tech has maintained a fairly constant ITL of around 5.5


![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/29k788paxQ9AF3bksWHWuB/da9f6822e69ea5ed48364c5ab8558561/Battling_Bots_02.png)


For our third example, let’s shift our attention to Healthcare (with a global aggregation and weekly granularity). It’s clear that around the beginning of March, bot activity targeting the Healthcare industry picked up significantly — jumping from a baseline ITL of around 3.5 to repeated peaks approaching 6.0!

Do providers of Healthcare apps know that they’re under siege — and would they configure their defenses differently if they knew?

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/Wb4zGX0ZgOOjDzlBYtD2M/1cf104b5bca618e3be5df9e2ed2aba82/Battling_Bots_03.png)

As our final example, let’s return our attention to Travel/Transportation, but this time we’ll go one level deeper and examine the ITL for three different geographies: the Americas (AMER), Asia-Pacific (APAC), and Europe, the Middle East, and Africa (EMEA).

From this breakdown, we can see that while the composite Travel/Transportation ITL tends to be in the range of 5.5 to 6.0, the threat level varies considerably by region: APAC and EMEA are largely in the 3.0 to 4.0 range, while the AMER score has remained above 7.0 for all of 2023!

![Battling Bots](https://images.ctfassets.net/23aumh6u8s0i/68RTbaQaVFgqNYO5rOsmJ0/23995c6abed960115b391617a78f184d/Battling_Bots_04.png)

## Looking Ahead

Anonymous firmographic metadata can help us not only to monitor _what_ is happening but also _why_. As a result, the ITL is about more than just observing attack trends — it’s about surfacing insights and informing actions to protect both providers and users of online services.

At the same time, ITL scores equip the broader security community with data that — until now — has only been available to a handful of organizations.

Ultimately, we’ve really only begun to scratch the surface of the insights that ITL scores can provide, and we invite you to join us on this journey of discovery.

Battling Bots: Introducing the Identity Threat Level (ITL)

johnathan-campos

Johnathan Campos is a Senior Product Marketing Manager at Okta focused on platform infrastructure and scalability. Johnathan is responsible for helping customers and partners understand the value of the Okta platform. Prior to joining Okta, Johnathan was a Senior Product Marketing Manager of the Observability Practitioner team at Splunk. During his time at Splunk, he helped practitioners understand the details of why Observability is the new necessary for native cloud deployments. When not focused on platform infrastructure and scalability, John enjoys tinkering in his garage, learning new things, spending time with family, and is an avid motorcycle fan.

Senior Product Marketing Manager, Global Platform Service

Johnathan Campos

With our new UK Region, we can enable local subscribers to achieve compliance and benefit from the quickest login response times available.

**TL DR;** The UK joins our available public cloud regions across EMEA to help with compliance requirements, data residency, and performance for our subscribers based in the UK.

We are thrilled to announce the launch of our newest region across our Customer Identity Cloud (Powered by Auth0) service in the UK. This new offering will provide a high-performance and secure way to manage customer identities while helping subscribers comply with UK data privacy regulations. As our first public cloud region on our converged platform architecture, this brings the latest cloud-native design and employs cutting-edge tools and fully automated operations to enhance business agility, developer productivity, scalability, reliability, and security for both our subscribers and platform teams. We encourage you to check out our blog series [here](https://auth0.com/blog/a-technical-primer-of-auth0-s-new-private-cloud-platform/) to learn more about our converged platform, and if you want to double-click even further on architecture, check out this blog [here](https://auth0.com/blog/the-architect-s-view-of-auth0-s-new-private-cloud-platform/) by my colleague, Leonardo Zanivan.

This public cloud region is also a major milestone in supporting UK customers with data residency needs. UK-based data centers will enable subscribers to store their data within the UK, helping ensure compliance with UK regulations for those that need it. This is particularly important for businesses that operate in heavily regulated industries, such as finance or healthcare, where data residency requirements can often be strict. To choose their preferred location, subscribers can easily select from a menu when creating their new tenant where the UK is now available. 

![UK](https://images.ctfassets.net/23aumh6u8s0i/7oWDzK3Dj7HVHwHlQ8XuoV/4f01fd4cb8bdaa926b07ab83c9009419/UK.png)

In today's constantly connected environment, where numerous users - from staff to customers - need access to mobile applications, websites, APIs, and portals from any location and device, we are proud to provide our subscribers with an IDaaS solution that delivers the essential scalability, reliability, and accessibility organizations require. Our goal has always been to simplify identity management for developers and IT professionals worldwide. 

With the new launch, users in and around the UK can experience reduced latency while logging in and solve many challenges faced with data privacy regulations. Don't hesitate to contact us for any questions or help regarding the newly launched UK Region. We are always here to help!

The UK Joins Existing EMEA Regions for Public Cloud Deployments!

MichaelW

Michael has worked in the security space for over 10 years, developing integrations for different vulnerability scanning, SIEM, and SOAR tools. He is passionate about discovering the exponential value that can be had by combining together multiple security datasets rather than using them on their own. As the lead on partner integrations for Pangea, Michael is working on bringing together a group of best-in-market security services for developers to use via API.

Senior Manager - Partner Integrations Pangea

Michael Weinberger

Pangea offers integrations to enhance security for new account registrations and logins

Do developers who are not security experts want to spend their valuable time developing security features? But _should they_, given the considerable room for error? 

Pangea helps remove this margin for error. Pangea is a comprehensive set of API-based security services that can quickly and easily be added to any cloud application, embedded as functions directly into the application source code. Pangea emerged from the idea that key security features should not be repeatedly reinvented by companies every time they build new products. 

Instead, with Pangea, application developers can access a wide selection of out-of-the-box security services to embed security easily in all of their applications. Comparable to AWS for compute APIs, Twilio for communications APIs, and Stripe for billing APIs, Pangea has created a single platform for security — [Security Platform-as-a-Service](https://www.prnewswire.com/news-releases/pangea-cyber-closes-26m-series-b-from-gv-decibel-and-okta-ventures-for-developer-first-security-framework-to-deliver-secure-apps-faster-301689531.html) (SPaaS).

## Keeping Security Simple with Pangea Integrations

As we like to say, Pangea makes it “dead simple to integrate security with just a few lines of code”. With a clear developer focus, Pangea simplifies the varied aspects of security that are required for virtually every application. 

Without Pangea’s SPaaS for developer-first security services, the security puzzle is made up of scattered commercial and open-source pieces. Usually, these pieces are not even API-first, which makes integrations difficult. Pangea specializes in bringing these pieces together in an API-first form, with consistent documentation and guaranteed services compatibility — making it easy for developers to embed security in their applications.

## Pangea Integrations for Marketplace

Three Pangea Integrations have been released for the Auth0 Marketplace — [Pangea - Domain Check](https://marketplace.auth0.com/integrations/pangea-domain-check), [Pangea - Embargo Check](https://marketplace.auth0.com/integrations/pangea-embargo-check), and the [Pangea - Validate Registration](https://marketplace.auth0.com/integrations/pangea-validate-registration). The Pangea - Validate Registration integration uses Pangea security APIs to validate new user registrations. This includes embargo checks using Pangea’s Embargo Check and domain score checks using Pangea’s domain intel service, which contains intelligence on over 390 million domain addresses. The results are all logged to the Pangea secure audit log service.

Configuration can then be done on the Pangea console to view and manage audit logs (redaction and retention), manage embargo lists, and select providers for domain scoring — with no additional code changes. 

## How the Pangea Integration Works

To use the Pangea Marketplace integration, you will need an Auth0 account and tenant as well as a Pangea account.

Pangea setup requires some light integration configuration before adding the Auth0 Action. Note that once the Action is successfully deployed, all new user registrations for a tenant will be processed by this integration. Before activating the integration in production, install and verify the Action on a test tenant.

Once the Action is added, new user registrations will be defended by Pangea APIs. Each new user registration will be checked against Pangea Embargo and Pangea Domain Intel. The user will either be accepted or rejected, and the results will be written to Pangea Secure Audit Log.

## Shifting “Left-of-Left”: Pangea Benefits 

Implementing Pangea provides a number of benefits, including: 

* **Prioritizing security from the get-go of app development**, i.e., shifting responsibility “left-of-left”. Pangea's library of APIs security and compliance requirements are addressed from the beginning, giving developers the ability to drop security into their app runtime code prior to publishing. This can reduce developer cognitive load while covering security from the outset. 
* **Leveraging security intel from leading providers**, such as Crowdstrike, DomainTools, and ReversingLabs, among others, in Pangea APIs.
* **Securing registration decisions with cryptographically secure audit logs**. Pangea audit logs provide built-in redaction and can be used to help meet compliance and regulatory requirements under GDPR, SOC2, HIPAA, and more.

## Simplify Application Security with Pangea 

It’s never been easier for developers to add security to their applications right out of the box. Check out the [Pangea - Validate Registration](https://marketplace.auth0.com/integrations/pangea-validate-registration) integration in the Marketplace to get started.

Pangea — Security with Ease, Now on Marketplace

A step-by-step tutorial on using Auth0 and Kotlin to implement basic login/logout in Android apps

Get Started with Android Authentication Using Kotlin

swale-nunez

Swalé Nunez is a polymath with a deep fascination for creativity and an uncontrollable desire to innovate. A creative whose creativity takes shape in the form of technology manifested through human-centered design. Through his disruptively unorthodox approach and advocacy for technology that is user-centric, he is helping to pioneer decentralized identity through user-controlled identity provisioning. <br>
He has architected robust identity and access management solutions across industries, including finance and government sectors, and continuously works to bring that level of security to consumer identity. Ushering in a hybrid architecture implementation, which offers enterprise-grade authentication with intuitive consumer-like ease of use. An implementation that introduces a more transparent profile data sharing model that gives users more control over the access and sharing of their profile data while streamlining onboarding and checkout for seamless digital interactions.

Founder - Iuncta, Inc

Swalé Nunez

Iuncta has a new integration on Auth0 Marketplace

Social logins have given developers an effortless way to address several of their onboarding challenges. With a simple integration that lets users sign up and sign in to applications using social accounts, developers remove considerable friction from the process. Auth0 eased the integration process further, letting developers choose which social login provider to use. The [most prevalent](https://www.okta.com/blog/2020/08/social-login/), Facebook, was generally the default. That integration alone not only helped eliminate password management but also showed increases in conversion rates and overall user engagement. But removing friction and easing a developer’s job is just the first part of this journey. It’s also about user trust.

## A Question of Trust

There has always been an element of trust involved in the social login relationship. But it’s changing. As the relationship between users and the applications they interact with has evolved, user expectations of that relationship have shifted as well. And trust is at the core of these expectations. A study by [MalwareBytes Labs](https://blog.malwarebytes.com/security-world/2019/03/labs-survey-finds-privacy-concerns-distrust-of-social-media-rampant-with-all-age-groups/) found that 95% of internet users don’t trust social media companies with their personal data. Those who responded to the survey showed distrust across all social media platforms. The same research found that 87% of respondents didn’t feel confident sharing their personal data online. The lack of user confidence and distrust is becoming evident in how often they make use of social logins today. 

With users becoming more informed about data privacy and the need to become more active in protecting their online identity, they expect a privacy-first login that will give them more control over and transparency in their data. A report from [PEW Research Center on Americans and their online privacy](https://www.pewresearch.org/internet/2019/11/15/americans-and-privacy-concerned-confused-and-feeling-lack-of-control-over-their-personal-information/) found that 84% of users stated they have little to no control over the data companies collect about them. As technology evolves and with the advent of blockchain technology, users are embracing the idea of having more control over their online identities, data, and transactions, and technology is evolving to help make this possible. Decentralized identity is one such approach.

## A User-First Approach to Online Identity

[Iuncta](https://iuncta.io/)’s user-first approach to identity and access management is built on a model emphasizing transparency that leads to trust. It prioritizes user privacy and enables user control, all consistent with its user-centered design approach. Iuncta is a social login with transparent data sharing and access to zero-party data, so users are always aware of what data is being shared, when, and with whom. A social login that gives users the control they deserve, ensuring trust, offering privacy, and establishing peace of mind.

Iuncta’s decentralized identity implementation allows users to act as their own identity provider online, introducing a more transparent profile-data-sharing model. With its hybrid architecture, developers can quickly and easily offer enterprise-grade passwordless authentication with an intuitive consumer-ready experience that is supported by Iuncta’s [mobile app](https://youtu.be/GN5VMTN_fm8). The Iuncta platform enables user identity on demand, streamlining onboarding and facilitating secure and effortless digital interactions between users and developers.

![Mobile App](https://images.ctfassets.net/23aumh6u8s0i/1yV0zNgYxkdaBNrtSWznCd/ac139374809ea4f043d22ed1db6dda18/01_mobile-app.jpeg)

### End-to-end authentication

The Iuncta solution manages the relationship between the developers and the users of their applications and is supported by a feature-rich cloud offering at the core of an end-to-end solution to consumer online identity management and licensing. 

The key elements in Iuncta’s layered implementation include:

* Developers (Client) – A minimalist module requires only a username for passwordless access.
* Web API/Mobile SDK – A comprehensive list of tools for seamless integration into the Iuncta cloud service offering.
* Cloud services – A feature-rich collection of core Iuncta ecosystem services. It is the control center for the extensive functionality list.
* Mobile app – A clean and intuitive user interface designed to make user interaction with the Iuncta platform natural and effortless. 

![Iuncta](https://images.ctfassets.net/23aumh6u8s0i/1uGGyQ3FBjMBIO34dhAawX/149ba6599cc169cd3c9f0232ba209ea1/02_end-to-end_authentication.png)

Iuncta’s hybrid approach combines a consumer-friendly user experience with enterprise-grade security without lengthy development time. As an official Auth0 partner in its [Marketplace](https://marketplace.auth0.com/integrations/iuncta), the integration only takes a button click and a few simple steps for developers. With an Iuncta partner account, developers get access to the complete list of web APIs and downloadable mobile SDKs, as well as a reference guide with documentation and code samples to enable customization.

## Transparency That Leads to Trust

Social logins don’t all operate by the same set of principles. This means that, despite the importance of transparency, as cited by users, privacy, control over data, and trust aren’t priorities for all social login providers. The most important factor to consumers when choosing to share personal data in its secure collection and storage, control over what data is being shared, and trust in the company, according to the [Agility PR report](https://www.agilitypr.com/pr-news/public-relations/covid-has-made-consumers-more-willing-to-share-data-what-do-they-expect-in-return/). Iuncta believes in these principles and puts them to work.

Through its transparent practices, Iuncta’s social login helps to facilitate this trust through privacy, security, and control. Iuncta meets current and future expectations through:

* Ethical, fair, and transparent data practices without massive data collection or secrecy 
* Passwordless, user-controlled authentication and access to personal data
* Multifactor authentication for additional layers of security
* Creating a channel for users to profit from managing access to their identity, an innovative value exchange model.

Putting transparency into practice, it becomes clear that the more users trust, the more willing they are to share their data; the more data they share, the better the experience. The better the experience, the more likely they are to return as paying customers. A little trust goes a long way. 

Let’s work together to re-establish trust. Check out our [integration in the Auth0 Marketplace](https://marketplace.auth0.com/integrations/iuncta).

A Better Social Login: Transparency That Leads To Trust

Learn how to add login, logout, and sign-up to Vue.js using a plugin, how to create vue-router guards, and how to make secure API calls from a Vue.js app.

The Complete Guide to Vue.js User Authentication with Auth0

shiven_ramji

Shiv is an experienced product executive and builder obsessed with creating beautiful products. He is the President of Auth0 at Okta, managing a $1B ARR business and overseeing the company’s product, data, security, and technology strategy and execution. Before Auth0 and Okta, Shiv was the SVP of Product at DigitalOcean, leading DigitalOcean’s products, pricing, and partnerships. Additionally, Shiv has held product leadership positions at global brands, including Amazon, NBCUniversal, LiveIntent, and The Nielsen Company. Shiv was the recipient of the 2023 Top Global CPO Award by the Products That Count community.

Beyond his current corporate focus, Shiv is deeply committed to fostering entrepreneurship and innovation, particularly in Africa. He is an active angel investor and startup advisor and also serves on the boards of [**Products That Count**](https://productsthatcount.com/) and [**Aiven.io**](http://Aiven.io).


President, Auth0

Shiven Ramji

Convert and protect customers at the login box and beyond

**TL;DR:** Okta has launched the [Auth0](https://www.okta.com/press-room/press-releases/okta-introduces-okta-customer-identity-cloud-to-help-businesses-grow-user/), powered by Auth0, with support for two use cases: Consumer Apps and SaaS Apps. This article explores the Consumer App use case and capabilities, as well as how app builders, digital leaders, and security teams can set their applications up for success with end-users, starting at the login box.

It doesn’t matter if you’re in the public sector or selling pizzas–for every organization, in every industry, digital business is just business now.

As consumers ourselves, we know the best apps are the ones that improve our daily lives, keep us safe online, and are delightful to use. We also know what a terrible login experience feels like: 83% of consumers have [abandoned a cart or signup due to an arduous login process](https://info.auth0.com/expectation-vs-reality), and 48% are frustrated by filling in long login or sign-up forms.

In the identity and access management world, this is called customer identity: Learning about your customers and securely building consent-based trust by understanding who they are and how they want to engage with you.

While managing customer identity is a relatively new concept for marketers, app builders and security teams have been wrestling with the complexity around identity and access for years.

What would happen if we treated identity as the “digital front door”? Could we make end-users more secure, help developers launch the next big app, or put an end to passwords?


## Consumer Identity Without Compromise

Auth0 for Consumer Apps enables app builders, digital marketers, and security teams to give end-users access to everything they need online in a convenient and secure way. Consumer-friendly capabilities like Passwordless, Progressive Profiling, and Adaptive Multi-factor Authentication (MFA) ready to go out of the box help maximize conversion, retention, and loyalty without adding friction or security risk. And our 100% focus on identity means we’re keeping an eye on the latest attacks and technologies for you, too.

“Flo is committed to building a better future for female health with the number one OB-GYN recommended app, a thriving community, and science-backed resources,” said Roman Bugaev, Chief Technology Officer at [Flo Health](https://auth0.com/case-studies/flo-health). “Auth0 allows us to provide personalized insights to our users in a thoughtful and secure way, so they can take control of their health. Improving the authentication experience has also helped us reduce churn during the login process, driving our signups 12 times higher since we made the change.”

Here are a few of the ways our customers are using Consumer Apps today.

### Acquire Customers With Just One Click

Asking consumers to create (yet another) password that meets certain complexity requirements results in lower customer acquisition rates, especially on input-constrained devices. Streamline registration with fewer passwords for users and fewer password resets for your support team with **Single Sign-On (SSO) and social logins**, MFA, and more out of the box. Want to do away with passwords entirely? You can start with multiple passwordless options without adding security risk.


### Personalize Experiences for Long-Term Loyalty

Today, digital marketing teams are effective at personalization and testing around the login box, but very few are doing this within identity. Considering that the login box is the gateway to digital experiences, this is a huge missed opportunity. Features like **Universal Login** make it possible to customize the login experience to your exact audience with any number of authenticators–even without your own dedicated identity team. This is a huge selling point for marketers and the developers they work with, who have a lot on their plates already.


### Collect First-Party Data Without Friction

Have you ever had someone ask for too much information on a first date? Long sign-up forms are the digital equivalent. With web cookies going away, digital teams are turning to features like **Progressive Profiling** to collect first-party data over time as consumers sign up and engage with their website or app. Less creepy? Yes. Even more effective for building trust and personalizing experiences? Definitely.


### Protect Revenue From Bots and Brute Force

[Credential stuffing](https://auth0.com/resources/whitepapers/2022-state-of-secure-identity-report) accounts for 34% of overall login traffic and outpaces normal traffic in some countries (61%) in the U.S. and verticals (more than 80% in retail), according to Okta’s 2022 State of Secure Identity Report. Distinguishing between legitimate users and would-be attackers requires finesse and can quickly become a full-time job. Our **Attack Protection** capabilities like Bot Detection, Breached Password Detection, Suspicious IP Throttling, and Adaptive MFA give security teams the tools they need to fight fraud without damaging the user experience.


## What’s New for Consumer Apps?

New product innovations for Consumer Apps were announced at Oktane22. Okta expects these features to be available by the end of Q2 2023, with support for Highly Regulated Identity as an Enterprise Add-on.

* **Passkeys support:** Passkeys are a replacement for passwords that make it faster and safer to sign into apps and websites on any device. The technology is phishing-resistant and uses a device — usually a fingerprint or facial recognition, or a PIN — to prove a user is who they say they are. We are making it easy for app builders to turn on passkeys with the literal flip of a switch.
* **Highly Regulated Identity:** While we’re enabling app builders to offer the most exciting experiences, we also recognize some of our customers operate in highly-regulated industries like banking or utilities. Highly Regulated Identity is a new toolset that allows customers to safeguard riskier transactions with extra security and policy control. We are taking steps toward enabling customers to reach Financial Grade API (FAPI) compliance with several new product innovations, including:
    * **Pushed Authorization Request (PAR):** A new OAuth endpoint that avoids passing any sensitive information on the front channel (e.g., all authorization details won’t appear in the browsing bar or search history).
    * **Rich Authorization Request (RAR):** A framework that enables fine-grained control over authorization for any use case, including communicating fine-grained details on a transaction (e.g., payment amount) and customized consent gathering (e.g., selecting a bank account as part of the consent step).
    * **Private Key JWT:** An authentication method that improves security posture by signing with a private key rather than a password or secret that can be intercepted and used by someone other than the intended recipient.
    * **Strong Customer Authentication (SCA):** A component of the European Union’s second Payment Services Directive (PSD2) that requires at least authenticating users with at least two factors: something they have (e.g., device or hardware key), something they know (e.g., password or PIN), and something they are (e.g., biometrics).
    * **Mutual Transport Layer Security (mTLS):** A type of authentication where access tokens can only be used by the application they were specifically issued for; thus, if a token is leaked, it can’t be used by the attacker. 
* **Security Center:** At Okta, we have insights from billions of authentications about the threats facing consumer apps. We want to make sure your entire cross-functional team has this same visibility. Security Center is a single pane of glass that enables security professionals to monitor in real-time, detect, and respond to potential identity security events–either directly through your dashboard or by integrating with the security stack of your choice. With comprehensive dashboards, visualizations, and controls tailored to customer identity scenarios, this is a powerful tool for keeping your customers secure and your app operating at the highest level.

Learn more about the Auth0 and how to turn your login box into an engine for growth at [https://www.okta.com/customer-identity](https://www.okta.com/customer-identity/).

**Footnote:** _Any unreleased products, features, or functionality referenced in this blog post that is not currently available, may not be delivered on time or at all. Product roadmaps do not represent a commitment, obligation, or promise to deliver any product, feature, or functionality, and customers should not rely on them to make purchase decisions._

Inside Auth0 for Consumer Apps

Oliver Wang

A product manager at Auth0 focuses on  Ecosystem and Extensibility.  With an engineering background, Oliver always puts developers' experience first.  He has mixed industrial experience as a Product Manager, Software Engineer and Data Analyst. This diverse profile unites different team members to deliver value to our customers. Besides work, you can catch him up on a ski hill in the Canadian Rockies.

Product Manager, Ecosystem

Geoffrey Goodman

I am a curious and driven person. Until my early twenties, I was one of the top-ranked Canadian slalom skiers. While still competing, I pursued dual business majors at a Liberal Arts college in Nevada, funded by academic and athletic scholarships. I then joined EY in Montreal, where I worked with all of the four major service lines and earned my CA title. I now work with the Valuations and Business Modelling group and I am pursuing my CBV designation. 
<br>
I am also a self-taught computer programmer. I am comfortable in any number of programming languages. I built a website and steward a community of thousands of people across the world who rely on and benefit from its services every day.

Staff Engineer

Customers can now add custom prompts or factors in their post-login flow

We are excited to share that our customers that use Actions -  Auth0’s flagship extensibility product - can now add custom prompts or factors in their post-login flow. This enables developers and partners to confidently record the completion of a factor upon returning after a custom redirect. Auth0 delivers more tools, features, and options for developers to give them the support and capabilities they need to customize their customer’s experience through pro-code flexibility.

We have introduced a new method to the API of post-login Actions when continuing the flow after a successful custom redirect. This method allows a customer and/or partner to store the completion of that custom factor right in the user’s session. What is powerful about this is that they can then check whether that customer record is in a user session in each login and skip that prompt if it’s there already. Because it’s stored in the user session itself, it benefits from any current and future session management features within the Auth0 product offering.

## What Is the Problem We Are Solving?

Historically, there was no good way for customers to use Actions to securely implement custom prompts or custom factors in a user-friendly way. They could use user metadata or application metadata, but those objects exist across all user sessions. There was also no good way for customers or partners to see whether a user on a specific device had completed the necessary factors to login. This meant forcing users to re-perform the custom prompt or factor more often than necessary.

As an example, let's say you’re a developer for a banking app that has a special requirement to use a custom multi-factor authentication service, and you want that authentication to be associated with a user's session and or device for added security. That is where the ability to add a custom prompt enables you to build that customer experience and address that need.

## See It in the Real Example!

Let's take a look at a real example! Below is a sample Actions code for a Partner Integration implementing a custom authentication factor.

On the `onExecutePostLogin`, we trigger the custom authentication method by using Actions Redirect to send users to the customer method URL with session token information.

```js
const CUSTOM_METHOD_URL = "https://path.to.prompt";
const PROMPT_TTL = 1000 * 60 * 60 * 24; // 24h

exports.onExecutePostLogin = async (event, api) => {
    if (
        !event.authentication?.methods.some((record) => {
            // Timestamps are rendered as IS08601 strings
            const timestamp = new Date(record.timestamp);

            return (
                record.name === CUSTOM_METHOD_URL &&
                timestamp.value0f() >= Date.now() - PROMPT_TTL
            );
        })
    ){
        const sessionToken = api.redirect.encodeToken({
            payload: {
                user_id: event.user.user_id,
            },
            secret: event.secrets.SESSION_TOKEN_SECRET,
        });

        // Trigger our custom authentication method
        api.redirect.sendUserTo(CUSTOM_METHOD_URL, {
            query: { session token: sessionToken }
        });
    }
};
```

Continue with `onContinuePostLogin`, we validate the session token secret and record the completion of our custom authentication method.


```js
exports.onContinuePostLoqin = async (event, api) => {
    const payload = api.redirect.validateToken({
        secret: event.secrets. SESSION_TOKEN_SECRET,
        tokenParameterName: 'session_token'
    });

    if (!validateSessionToken(payload)) {
        return api.access.deny('Unauthorized');
    }

    // Record the completion of our custom authentication method.
    // THIS NEW API IS ONLY AVAILABLE IN 'onContinuePostLogin'
    api.authentication.recordMethod(CUSTOM_METHOD_URL);
};

function validateSessionToken(payload) {
    // Custom validation logic would go here
    return true;
}
```

Actions is an iterative platform we continually improve upon. [Start creating your Auth0 Actions](https://auth0.com/docs/customize/actions/write-your-first-action) today and customize your logic flow with the seamless low-code integration with Auth0!

New Actions Feature: Build Your Own Custom Factor

A step-by-step tutorial on using Auth0 and Swift to implement login/logout and use user metadata in iOS apps.

Get Started with iOS Authentication using Swift and UIKit

sambiopic

I'm Director of Developer Relations and a Google Developer Expert for Angular and Web Technologies. I believe anyone who wants to learn to code should be able to learn code and I love teaching. When I'm not coding or writing, you'll find me outside hiking or camping in the beautiful Pacific Northwest.

Director of Developer Relations

Sam Julien

Learn why the login box alone just won't cut it – and how to move beyond it – as life and development continue to evolve.

Join us for Developer Days 2022 and discover life beyond passwords. Registrations are open for our Seattle, Sydney, London, and Berlin. Save your seat today!

<AmpContent>

<b>Seattle</b><br>Wednesday<br>August 24, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySeattle2022">Check out Seattle</a><br>

<b>Sydney</b><br>Tuesday<br>September 6, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySydney2022">Check out Sydney</a><br>

<b>London</b><br>Thursday<br>September 29, 2022<br><a href="http://regionalevents.okta.com/DeveloperDayLondon2022">Check out London</a><br>

<b>Berlin</b><br>Wednesday<br>October 5, 2022<br><a href="https://regionalevents.okta.com/DeveloperDayBerlin2022">Check out Berlin</a><br>

</AmpContent>

<NonAmpContent>
<style>
table {
  border-collapse: collapse;
  width: 100%;
  border: 1px solid #ddd;
}

th, td {
  text-align: left;
  padding: 16px;
}
</style>
<table>
  <tr>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/1nkZ0XesAUpHE0oIKVIgIB/fc02efba5f1a93f97e33ad24b2ebd91c/01.png" width="" alt="alt_text" title="image_tooltip"></td>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/5LivuzVqbtafwH02otDCH3/40282613c247bc618ecf51a6ad5cd971/02.png" width="" alt="alt_text" title="image_tooltip"></td>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/3JJNwJHTMr3ls6scSAlZRW/1028eb4a16d72a9bbce6b31bc075e8bb/04.png" width="" alt="alt_text" title="image_tooltip"></td>
   <td><img src="https://images.ctfassets.net/23aumh6u8s0i/3as5x6Y9szXH7RtUlpbwlq/474ef5b1162728a31885314052951cd8/03.png" width="" alt="alt_text" title="image_tooltip"></td> 
  </tr>
  <tr>
   <td><b>Seattle</b><br>Wednesday<br>August 24, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySeattle2022">Register now for Seattle</a></td>
   <td><b>Sydney</b><br>Tuesday<br>September 6, 2022<br><a href="http://regionalevents.okta.com/DeveloperDaySydney2022">Register now for Sydney</a></td>
   <td><b>London</b><br>Thursday<br>September 29, 2022<br><a href="http://regionalevents.okta.com/DeveloperDayLondon2022">Register now for London</a></td>
   <td><b>Berlin</b><br>Wednesday<br>October 5, 2022<br><a href="https://regionalevents.okta.com/DeveloperDayBerlin2022">Register now for Berlin </a></td>
  </tr>
</table>
</NonAmpContent>

<br>

As technology evolves, life and development have more complex demands than a simple login box can meet. Learn modern techniques for building more secure apps from industry and community leaders, and try them out in our hands-on interactive labs. Auth0 technical experts will be on-site to support one-on-one architecture reviews and offer opportunities to make new connections between sessions.


![Developer Day 2022](https://images.ctfassets.net/23aumh6u8s0i/tJ507YxFgmC38a6GBVtsI/875f64920ba57e637afc6ee9a966ea48/dd2022.jpg)

For further information, visit our [Developer Day site](https://regionalevents.okta.com/DeveloperDays2022).

Developer Day 2022: Registrations Open!

Learn how to implement login, logout, and user profiles in Android apps using Kotlin and Auth0.

Get Started with Android Authentication Using Kotlin: Part 2

Get Started with Android Authentication Using Kotlin: Part 1

Majid Hajian

I am a Google Developer Expert and Media Developer Expert and a passionate software developer with years of developing and architecting complex web and mobile applications. my passions are Flutter, PWA, and performance. I love sharing my knowledge with the community by writing and speaking, contributing to open source, and organizing meetups and events.

Google Developer Expert

In this tutorial, you’ll learn how to enhance your Flutter apps by enabling authentication, supporting federated identity providers, adding authorization by introducing roles and permissions, all leveraging Auth0.

In the exercise from the previous section, you added Auth0 authentication to an existing Flutter app. This added a username/password authentication flow to the app. You also gave the app the ability to request and submit refresh tokens, which enhance the user experience by not requiring the user to authenticate every time they use the app.

This section will expand on the app by examining some useful Auth0 features:

* Refresh token rotation
* Social logins
* Managing your Auth0 account

> **Look for the 🛠 emoji if you’d like to skim through the content while focusing on the build and execution steps.**


## Add Refresh Token Rotation

When the app makes an authentication request to Auth0’s authentication server, it includes the `offline_access` scope. This causes the authentication server to issue a refresh token, which the app can use to re-authenticate without requiring the user to log in again. The app stores this token in the device’s secure storage.

While this enhances the app’s user experience, it also introduces risk. The refresh token is long-lived, and the app could use it as a “lifetime pass” to endlessly request new access tokens and keep the user logged in forever.

I highly recommend taking advantage of *Refresh Token Rotation* and *Automatic Reuse Detection* to help mitigate this risk. With these features enabled, each refresh token can be used only once. When the app exchanges its refresh token for a new access token, the authentication server also returns a new refresh token and invalidates the old one. 

Let’s enable these features!

🛠 Navigate to the **Applications** section of your Auth0 dashboard, select the **MJ Coffee** application, and then select its **Settings** tab. Scroll down the page to the **Refresh Token Rotation** section and turn on the **Rotation** and **Absolute Expiration** options:

![Turn on the “Rotation” and “Absolute Expiration” options.](https://images.ctfassets.net/23aumh6u8s0i/6EizPZZnkGjxoAOle1Q8eL/e06c99f4a49413572736bbf0f470436c/rotation_and_absolute_expiration.png)

It is recommended that you issue a refresh token that expires after a preset lifetime. The refresh token’s lifetime can be extended each time one is used to get a new access token or access token/refresh token pair.

There are two options for token lifetimes, and they can be set independently of each other:

- **Absolute Lifetime:** Enabling **Absolute Expiration** sets a specified *absolute lifetime* for the application’s refresh tokens. Refresh tokens can be exchanged for new access tokens during this lifetime. Once the token’s age goes past its lifetime, the user will need to re-authenticate in order to get a new access token. If **Absolute Expiration** is disabled, the refresh token has an indefinite absolute lifetime.
- **Inactivity Lifetime:** Enabling **Inactivity Expiration** specified *inactivity lifetime* for the application’s refresh tokens. Refresh tokens can be exchanged for new access tokens if the user is active in the application during this lifetime. If the user is inactive in the application for a period longer than the inactivity lifetime, they will need to re-authenticate in order to get a new access token.

🛠 Scroll to the bottom of the page and click the **Save Changes** button:

![The “Save Changes” button. The user is directed to click it.](https://images.ctfassets.net/23aumh6u8s0i/7KsLW4adJ6PNIPAI12al4g/f2c0e8abf6d7377595cfb7df11493e67/save_changes.png)


## Social Logins

These days, it's pretty common to have login methods beyond the standard username/password combination. These include logging in with social media account, which will significantly enhance your users’ experiences.

Implementing these additional login methods and adding them to your authorization server is time-consuming and will come with many considerations and risks. 

Luckily, Auth0 provides lots of integration with well-known third parties’ authentication systems, and even allows you to write your custom connections. Let's add connections to both Google’s and Apple’s authentication systems.


### Create a Google/Gmail social connection

🛠 In the Auth0 dashboard, select **Authentication** in the left column menu, then select **Social**. This takes you to the **Social Connections** page, where you should click the **Create Social Connection** button:

![The steps to create a new social connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/61w1eXrbY7bGOpNo6ODbaU/da810c63bacd28cabf71e6dee4baa349/create_social_connection.png)

You will be taken to the **New Social Connection** page, which has a list of social login providers that integrate with Auth0. 

🛠 Select **Google**:

![Selecting Google from all the available social connections](https://images.ctfassets.net/23aumh6u8s0i/2YdUxIkwmCTcc9QFlo584q/22f7fd0bf4bc1c93c4ebc555e21009f8/select_google.png)

You will now be on the  **New Google / Gmail Social Connection** page, which tells you what kind of user information is accessed by Google social login.

🛠 Click **Continue**:

![Initial page for creating a new Google/Gmail social connection](https://images.ctfassets.net/23aumh6u8s0i/2SQwtF0vqtXJucnGbE3DNS/baf5bd9d7103a6ecbd59b879bbe2aaf4/click_continue.png)

A new page with a number of fields will appear; this is the connection’s **Settings** tab. 

As long as you’re working in a development environment, you only need to fill the **Name** field (which provides a name for this connection) and leave all the other fields empty. You can always use the default value in the **Name** field:

![New Google/Gmail social connection](https://images.ctfassets.net/23aumh6u8s0i/7Jzsn4ryILOOdACN2urlSo/fdaa205ef09352c0b9aba0acbd592977/new_google_gmail_social_connection.png)

However, production apps require you to provide a **Client ID** and **Client Secret** ([doc](https://auth0.com/docs/connections/social/google)) and specify the **Allowed Mobile Client IDs**. These topics will be covered in another video or article.

🛠 Create the Google/Gmail connection by scrolling to the bottom of the page and clicking **Create**:

![Creating the Google/Gmail connection](https://images.ctfassets.net/23aumh6u8s0i/4S8AJUaj4xehVwVxhNDt5X/69eb88b8bec557d310d0e9d678fe9b7e/click_create.png)

This will create the connection, and you’ll be taken to its **Applications** tab. You’ll see a list of your applications, which will allow you to enable the Google/Gmail connection for any of them. Enable the connection for the *MJ Coffee* application:

![The Google/OAuth2 applications tab](https://images.ctfassets.net/23aumh6u8s0i/681u1RRcha4ABJJ5GRZivy/c7eea90ca4e19ec5ab3b333caa47e5ba/google-oauth2_applications_tab.png)

You may also set more permissions that the end-user will need to approve during authorization. These permissions depend on your application and what you want to do on behalf of the user. The *MJ Coffee* app doesn’t need any extra permissions beyond the basic and extended profile.

![Google Permission](https://images.ctfassets.net/23aumh6u8s0i/13CvLX8tQUTuqU6jpZ6K94/a0eaac13b8fc83fc11b3ca3f6651ebd9/google_permissions.png)

🛠 Make sure you sync user profile attributes at each login and hit the **Save** button.


### Create an Apple ID social connection

🛠 Once again in the Auth0 dashboard, select **Authentication** in the left column menu, then select **Social**. This takes you to the **Social Connections** page, where you should click the **Create Social Connection** button:

![The steps to create a new social connection in Auth0](https://images.ctfassets.net/23aumh6u8s0i/1sohaZxDHuq8X8ZvT5nhvE/d2b7a7e2647708327f8fc6971ddb43a9/create_connection.png)

🛠 This time, select **Apple**:

![Selecting Apple from all the available social connections](https://images.ctfassets.net/23aumh6u8s0i/3JAgbtDSNOsfYrjxkE1wCI/e51d80f7418706c29cd6e9dc06b93719/select_apple.png)

You will now be on the  **New Apple Social Connection** page, which tells you what kind of user information is accessed by Apple social login.

🛠 Click **Continue**:

![Continue](https://images.ctfassets.net/23aumh6u8s0i/3zt2ntLwoHwp6bldLmOOsD/8db3e7f5c057d5782c7202b748013420/click_connect_-_apple.png)

As long as you’re working in a development environment, you can leave the **Client ID** and **Client Secret Signing Key** fields empty. You *will* need proper keys for those fields when the app goes to production; [this document covers that topic in more detail](https://auth0.com/docs/connections/apple-siwa/set-up-apple).

The **Apple Team ID** and **Key ID** values are required:

![Google Permission](https://images.ctfassets.net/23aumh6u8s0i/2qNvT5zkxB1TY06ywkH5Re/7c46fa1399743de9e7bb05d1d804fab0/apple_dev.png)

* To get your Apple Team ID, you need an Apple Developer Account.
* To get a Key ID for your app, you need to register that app using your Apple Developer Account. 

🛠 Sign in to your Apple Developer Account, and go to the **Membership** page and make a note of your Team ID.

🛠 If you have a registered app, you can skip the following steps and jump to the list of tasks for creating a service ID. Otherwise, follow the steps below:

- In the Apple Developer Portal, go to **Certificates, IDs, & Profiles > Identifiers** and click the blue “plus” icon next to **Identifiers** to create a new App ID.
- Choose **App IDs** as the identifier type and click **Continue**.
- Provide a description and a Bundle ID in reverse-domain name format (e.g.: `com.mydomain.mjcoffee`).
- Scroll down and check **Sign In with Apple**.
- Click **Continue**, and then click **Register**.

🛠 Once the app is registered, it’s time to create a service ID:

- Return to the **Certificates, IDs, & Profiles** section, and click the blue “plus” icon next to **Identifiers**.
- Choose **Service IDs** and select **Continue**. Fill in the description and identifier (e.g.: `com.mydomain.mjcoffee`).
- After checking **Sign In with Apple**, select **Configure**, and define your Web Domain (e.g.: `com.mydomain.mjcoffee`) and your "Return URL". Ensure that your Return URL is your Auth0 domain and that it follows this format: `https://YOUR_AUTH0_DOMAIN/login/callback`.

![Return URL apple sign in](https://images.ctfassets.net/23aumh6u8s0i/5Wetff0Tutv55UXsYz0gKq/ab19cd3e48604aea314410d22d194982/callback_apple.png)

🛠 Finally: save, continue and then register the service.


#### Set up your Client Secret Signing Key

🛠 Follow these steps:

- Go to **Keys**, which is located in the **Certificates, Identifiers, & Profiles** section of your Apple developer dashboard.
- Select the blue “plus” icon to add a new key.
- Enter a **Key Name** and check the **Sign In with Apple** option.
- Select **Configure** to make sure the **Choose a Primary App ID** field is filled with the correct App ID.
- Select **Save, Continue**, and then **Register**.
- On the page to which you're redirected after registering, make a note of the Key ID. Then download the key; it will have a `.p8` filename extension.

🛠 Go back to your Apple social connection settings and paste the Key ID. Ensure the proper attributes are selected (Name, Email) and sync user profile at each login is enabled. Hit **Save**.


## Enable Social Connections

🛠 Once you have created all your social connections and set them up correctly, go back to your applications. Go to the **Connections** tab and enable your newly-made social connections:

![app social connections](https://images.ctfassets.net/23aumh6u8s0i/59SCRbiX055qDcmTSNwPVl/fa175f974ceb43515893f24f7747d549/app_social_connections.png)

As you can see, adding and removing social connections for your apps is now as simple and flicking a switch.

On the Flutter side, I have good news: you don’t need to implement anything there! 

Restart the app, log out, then try to log in. You’ll see this:

![app social connections](https://images.ctfassets.net/23aumh6u8s0i/4b6BIaeZ8EHcN1a3MYVOrF/91c9039cf0d56051c99397d1a7524a3e/social_buttons_flutter.png)

That's it! The login screen will now display social login buttons, and their login flows will be ready to use.


## Branding 

While it’s fine to use the default branding in development, you want the login page to be customized to your “look and feel” once the app’s in production.

Auth0 allows you to customize your login page through a number of options. You can change the look and feel of the login page by adding colors and logos, and you can customize the user notification part of the process as well: email templates, text messages, and so on. It’s all in the **Branding** section of the Auth0 dashboard:

![Auth0 branding](https://images.ctfassets.net/23aumh6u8s0i/7oq6VzFQ3nSUcStZTXvjQu/38d1e272f3bef751d9feaca704d580dc/branding.png)


### Add Roles

You may want to provide certain functionalities to the user based on their roles. This is easy with proper authorization server such as Auth0, which facilitates adding roles and specifying what users in each role are allowed to do. 

In the MJ Coffee app, there are three different roles:

- **Admin:** These are administrators, and they will have access to all the app’s functionality with full permissions.
- **Customer:** This is the default role for registered or logged-in users. They are limited to the app’s customer-facing features. You will automatically assign this role to all users upon registration or login, and you will learn how to do so later on in this tutorial.
- **Employee:** These are coffee shop employees. They can access the community screen to answer customer requests in the support chat, as well as other employee-facing features.

![Auth0 roles](https://images.ctfassets.net/23aumh6u8s0i/7nVdiU86TPCF1tLXrBg6ID/54a078bfe7d2382a6776c26adfc5cba4/roles.png)

You can add more roles to the app as the need arises.


## User Management in Auth0

Auth0 provides the infrastructure to store users and their information on its cloud database.

For the *MJ Coffee* app, Auth0’s cloud database is sufficient. One of Auth0’s goals is to reduce the cost of extra infrastructure maintenance and cost.

You can access users by selecting **User Management** in the left column menu of the Auth0 dashboard. The **Users** page allows you to create new users and manage your existing ones by changing their details, adding permissions and roles, or revoking their access.

![Auth0 users](https://images.ctfassets.net/23aumh6u8s0i/3O0JDGBqXHmPfrKaEavP2D/260c804cf50a308e696ecd9a446ab4a9/users.png)

When you open a user, you’ll see that Auth0 provides in-depth details about that user, including basic account data, metadata, their devices, and their history, which might be pretty helpful for debugging the application or investigating a particular user’s access activity, permissions, and roles.

![Auth0 user roles](https://images.ctfassets.net/23aumh6u8s0i/JcGTMspZ9hKtu9RAi4Oq9/257a692aa9a65cd12e96f645b56aafd1/user_roles.png)

Each user account stores some basic information about the user: name, email address, the date and time when the account was created, and so on. 

Additional information can be attached to a user by adding to these metadata stores:  their user metadata, which is a key-value structure for storing information about the user. You can also store information in the user_metadata or manipulating `app_metadata`, which helps to provide more information to the Flutter application while receiving user details.


## Moving Forward

In the next section of this tutorial, you will learn how to add real-time chat to the app.


"Login"