Auth0 Certified Developer Study Guide

Author: Adam Cerny

Introduction

Preparing for the Auth0 Certified Developer Exam requires more than a surface understanding of identity and access management. It involves developing a clear grasp of how the platform behaves in practice, including its APIs, configuration options, supported protocols, and security mechanisms.

This guide was created during my own preparation for the exam, with the goal of bringing together key details from the documentation, training materials, and hands-on experience into a single structured resource. It focuses on the areas that are often overlooked but frequently tested, such as exact parameter names, default settings, limitations, and the subtle differences between related features.

The intention is not to replace the official learning materials but to complement them. It provides a concise, technically focused reference designed to support effective revision and build confidence when approaching the more detailed and scenario-based questions in the exam.

Before You Start

Success in the Auth0 Certified Developer Exam depends on preparation and familiarity with how the platform behaves in real-world use. Below are some practical tips and study advice based on my own experience preparing for the exam.

Complete all of the Related Learning modules listed in the official Auth0 Certified Developer Study Guide, including the codelabs.
Take notes on any topics that appear in the short tests at the end of each section, as many of these concepts reappear in the real exam.
For the codelabs, register a new Auth0 tenant for each lab to keep your environment clean and avoid configuration conflicts.

2. Go Beyond the Study Guide

Do not expect to pass the exam by completing the study guide alone.
The real exam goes into fine detail, much of which is not covered in the related learning. Read the official documentation to fill in gaps, but do not feel you need to memorise everything. Focus on taking clear notes on areas where your understanding feels weaker.

3. Practice Exams

The practical section of the exam is worth roughly half the total score, and if you follow the instructions carefully you can get close to full marks. So do not panic if you have to make a few educated guesses on the DOMC questions — a strong performance in the practical can easily balance things out.

4. DOMC Question Tips

The exam uses DOMC (Discrete Option Multiple Choice) questions. Each option appears one at a time, and you must decide immediately whether it is correct.
Here are some key tips:

5. Exam Day

Allow around 40 minutes to get set up with the proctoring company. This will start at the time you have scheduled your exam, so factor that in when planning how long the exam will take in total. Make sure you understand the requirements for ID verification, desk space, and allowed materials before your scheduled time.
Use wired peripherals (mouse, keyboard, speakers) if possible. If you use wireless devices, you will need to show the USB dongle to the proctor, which can be awkward if it is connected tot he bottom of a monitor or anywhere else not easily accessible.
Ensure your workspace is clear, your internet connection is stable, and you have your ID ready.

Part I: Discrete Option Multiple-Choice (DOMC) Exam Subjects

Section 1: Planning and Designing an Auth0 Implementation

Foundational decisions made during the planning and design phase have cascading effects on an application’s security, user experience, and extensibility. Exam questions in this domain test the understanding of Auth0’s architectural building blocks and the security implications of fundamental configuration choices.

1.1 Application and Client Types: The Definitive Guide

The selection of an Application Type within the Auth0 Dashboard is a foundational step that dictates available settings and recommended authentication flows. This choice is immutable for Machine-to-Machine applications and is often locked for other types once certain grant types are selected, underscoring its architectural importance.

The four primary application types are:

A core concept from the OAuth 2.0 specification that underpins these types is the distinction between confidential and public clients. This classification is based entirely on an application’s ability to securely store its Client Secret.

This distinction has a critical and direct impact on token security. The Client Secret is used for symmetric signing algorithms like HS256, where the same key is used to both sign and verify a token. For a public client to use HS256, it would need to embed the secret within its code, making it vulnerable. An attacker who extracts this secret could forge valid ID tokens, completely compromising user authentication.

To prevent this, public clients must use an asymmetric signing algorithm, RS256. In this model, Auth0 signs the token with a private key that is kept secret on Auth0’s servers. The public client then verifies the token’s signature using a corresponding public key, which it retrieves from a publicly accessible JWKS (JSON Web Key Set) endpoint provided by the Auth0 tenant at https://{yourDomain}/.well-known/jwks.json. Because the client only needs the public key for verification, it has no secret to protect. Confidential clients, with their ability to protect a secret, are permitted to use either HS256 (symmetric) or the recommended RS256 (asymmetric) algorithm.

The following table consolidates these critical relationships for memorisation.

Application Type Client Type Can Store Secret? Recommended Flow
Regular Web App Confidential Yes Authorization Code
M2M App Confidential Yes Client Credentials
Single Page App Public No Authorization Code + PKCE
Native App Public No Authorization Code + PKCE

1.2 URI Configuration: Syntax and Placeholders

The “Application URIs” section in the application settings is a critical security boundary. Auth0 enforces that it will only redirect users to URLs that have been explicitly whitelisted in these fields, preventing open redirect vulnerabilities.

Custom domains

For multi-tenant B2B applications that use the Auth0 Organisations feature, a more secure and dynamic method for handling customer-specific subdomains is available. Instead of using a risky wildcard, the {organization\_name} placeholder can be used in the Allowed Callback URLs, for instance: https://{organization\_name}.myapp.com/callback.

Using a wildcard like *.myapp.com creates a vulnerability because an attacker could potentially register a subdomain (e.g., malicious.myapp.com), initiate a login flow, and trick Auth0 into redirecting an authenticated user—along with their sensitive authorization code—to the attacker-controlled server. The {organization_name} placeholder mitigates this threat. Auth0 will only substitute the names of organizations that are legitimately registered and configured within the tenant. An attacker cannot forge a redirect to an arbitrary subdomain; it must correspond to a known and trusted entity within the Auth0 configuration.

1.3 Token Strategy and Security

A robust token strategy is essential for maintaining application security and performance.

1.4 User Migration Strategies

For applications transitioning to Auth0 from a legacy identity system, two primary migration strategies are available.

Section 2: Authentication

This section delves into the mechanics of user authentication, covering the standard protocols, logout procedures, and specific features that define the login experience.

2.1 Authentication Flows: A Comparative Matrix

Auth0 provides robust support for standard OAuth 2.0 and OIDC flows, abstracting much of their complexity. The appropriate flow is primarily determined by the application’s client type.

Flow Name Recommended Application Type Client Type Key Security Characteristics Primary Use Case
Authorization Code Flow with Proof Key for Code Exchange (PKCE) Single-Page App (SPA), Native/Mobile Public Does not require a client secret. Uses a dynamic proof key (PKCE) to prevent authorization code interception attacks. Considered the most secure flow for public clients. User authentication and API access for applications that cannot securely store a secret, such as browser-based SPAs and mobile apps.
Authorization Code Flow Regular Web App Confidential Requires a client secret, which is exchanged securely on the back-channel. Tokens are never exposed to the user’s browser. User authentication and API access for traditional server-side applications that can securely store a client secret.
Client Credentials Flow Machine-to-Machine (M2M) Confidential Non-interactive flow. The application authenticates itself directly using its client ID and secret to obtain an access token. No user is involved. Granting API access to backend services, daemons, CLIs, or other non-interactive clients.
Implicit Flow with Form Post (Legacy) Single-Page App Public Discouraged. Tokens are returned directly in the URL fragment, which can expose them to interception. Lacks support for refresh tokens. Legacy use case for simple user authentication in SPAs where only an ID Token was needed. Superseded by Authorization Code Flow with PKCE.
Resource Owner Password Flow (Legacy) Highly Trusted First-Party Apps Confidential Discouraged. Requires the application to collect the user’s username and password directly, breaking the principle of delegation and increasing security risks. Should only be used when redirect-based flows are impossible. Legacy systems or specific command-line tools where a browser-based redirect is not feasible.

OAuth 2.0 / OIDC Flows — Step by Step

This section describes how the main flows work in Auth0, aligned with their recommended application types.

Authorization Code Flow with PKCE (for SPAs and Native Apps)

Who uses it?
Single-Page Applications (SPAs) and Native/Mobile apps — public clients that cannot keep a secret.

Steps:

  1. App initiates login
    • The SPA/native app redirects the browser (or in-app browser) to Auth0’s /authorize endpoint.
    • It includes a code_challenge (a hashed random string) and specifies response type code.
  2. User authenticates
    • User enters credentials, or signs in with an IdP via Universal Login.
    • Auth0 creates a session (cookie) and validates user identity.
  3. Authorization Code returned
    • Auth0 redirects back to the app’s redirect URI with an authorization code (in the URL).
    • No tokens are exposed at this stage.
  4. Token exchange with PKCE
    • The app sends the authorization code + its original code_verifier (the secret string matching the challenge) to Auth0’s /oauth/token endpoint.
    • No client secret is needed.
    • Auth0 checks that the hashed verifier matches the earlier challenge.
  5. Tokens issued
    • Auth0 returns an ID token, Access token, and optionally a Refresh token.
    • Tokens are stored securely in memory (for SPAs) or OS-secure storage (for native apps).

Security Characteristics:

Authorization Code Flow (for Regular Web Apps)

Who uses it?
Server-side rendered web apps (Node.js, Django, ASP.NET) — confidential clients that can keep a secret.

Steps:

  1. App initiates login
    • Browser is redirected to Auth0’s /authorize endpoint with response_type=code.
  2. User authenticates
    • User logs in at Auth0 (Universal Login).
    • Auth0 sets its session cookie.
  3. Authorization Code returned
    • Auth0 redirects to the app’s redirect URI with the authorization code.
  4. Server exchanges code with client secret
    • The app’s backend (safe environment) sends the code + client_id + client_secret to /oauth/token.
    • This happens over a secure back-channel (not exposed to the browser).
  5. Tokens issued
    • Auth0 returns an ID token and Access token (and optionally Refresh token).
    • The server can set a session cookie for the user, hiding tokens from the browser.

Security Characteristics:

Client Credentials Flow (for Machine-to-Machine apps)

Who uses it?
APIs, backend services, daemons, CLIs — confidential clients with no user present.

Steps:

  1. App requests a token
    • The service posts directly to /oauth/token with its client_id and client_secret.
    • It includes the audience of the API it wants to call.
  2. Auth0 validates credentials
    • Auth0 checks the client_id/secret pair.
    • Ensures the app is authorised to request tokens for that API.
  3. Access token issued
    • Auth0 returns an Access token scoped for the requested API.
    • No ID token is returned because no user exists.
  4. App calls the API
    • The app uses the access token in the Authorization: Bearer header.
    • The API validates the token (signature, audience, scope).

Security Characteristics:

Memory Tips:

What is OIDC (OpenID Connect) and What Does It Apply To?

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework.

Key distinction: OAuth 2.0 alone is about authorisation (can you access this resource?).
OIDC adds authentication (who are you?).

Memory Aid: OAuth 2.0 vs OIDC

Aspect OAuth 2.0 (alone) OIDC (OAuth 2.0 + identity layer)
Primary Purpose Authorisation (granting access to resources) Authentication + authorisation
Main Token Access Token Access Token + ID Token
ID Token Format N/A JWT containing identity claims
Typical Use Case A service calling an API on behalf of a user A client app logging a user in and knowing who they are
SSO Support Not specified Built-in, using ID Token and standard claims

Memory tip: OAuth tells you what you can do. OIDC tells you who you are.

2.2 Logout Scenarios and Session Layers

Properly implementing logout requires an understanding of the different session layers that can exist during an authenticated user’s journey.

There are three distinct session layers to consider:

  1. Application Session Layer: This is the session managed directly by the application itself, often implemented with a session cookie. The application is solely responsible for creating and clearing this session.
  2. Auth0 Session Layer: Auth0 maintains its own session for the user via a cookie set on the authorization server’s domain. This session enables Single Sign-On (SSO). Logging out of this layer clears the SSO state.
  3. Identity Provider (IdP) Session Layer: If a user authenticates via a federated IdP like Google or a SAML provider, they will also have an active session with that provider.

RP-Initiated Logout is the standard OIDC mechanism for logging a user out. The application (the Relying Party, or RP) initiates the process by redirecting the user to Auth0’s /oidc/logout endpoint. Key parameters for this endpoint include:

The distinction between application-level and tenant-level logout URLs is a matter of context and specificity. If the logout request includes a client_id, Auth0 has the context of a specific application and will only permit redirects to URLs listed in that application’s “Allowed Logout URLs” setting. If no client_id is provided, Auth0 falls back to the global list of “Allowed Logout URLs” configured at the tenant level, providing a more generic but less specific security boundary.

Back-Channel Logout is a server-to-server mechanism where Auth0 sends a signed logout_token to a pre-registered endpoint on each application’s backend, notifying them to terminate the user’s session. This is effective for traditional web apps with server-side sessions.

Universal Logout enhances this by also revoking any active refresh tokens for the user, providing a more thorough logout for SPAs and native apps that rely on them.

2.2.1 Backchannel and Frontchannel Logout Details

Front-channel logout

Back-channel logout

OIDC RP-Initiated Logout and global logout

2.3 Advanced Authentication Patterns

Auth0 supports several advanced patterns to customize the login experience.

2.4 JWT Structure and OIDC Claims

A JSON Web Token (JWT) is a compact, self-contained standard for transmitting information as a JSON object. It is composed of three parts, separated by dots: Header.Payload.Signature.

OpenID Connect (OIDC) defines a set of standard scopes that an application can request during authentication. These scopes correspond to specific sets of user attributes, or claims, that will be included in the ID token.

Requested Scope(s) Key Claims Returned in ID Token
openid sub (user ID), iss (issuer), aud (audience), exp (expiration), iat (issued at)
openid profile All of the above, plus: name, nickname, picture, given_name, family_name
openid email All of the openid claims, plus: email, email_verified
openid profile email All of the claims from all three scopes

The openid scope is mandatory for any OIDC-compliant authentication request and signals the intent to authenticate the user.

2.5 Embedded Login and Cross-Origin Authentication

When to use
Embedded login renders the login experience inside your app, not on the hosted Universal Login domain. It is generally discouraged for new builds, but you may see exam questions on how to enable it safely.

Key requirements

Notes for SPAs

Passwordless endpoints to remember

Section 3: User Provisioning and Management

This domain covers the lifecycle of a user account within Auth0, from creation and data storage to access control and multi-tenancy.

3.1 User Profiles: Metadata and Linking

Auth0 provides a flexible system for storing user data, centered around a normalised user profile and two types of metadata.

3.2 Role-Based Access Control (RBAC)

Auth0’s core authorization feature set provides a robust implementation of RBAC for securing APIs.

3.3 Auth0 Organizations for B2B/Multi-Tenancy

Auth0 Organizations is a feature set designed specifically for B2B and SaaS applications that need to manage distinct groups of users, such as different customer companies.

3.4 Progressive Profiling and Profile Enrichment

Progressive Profiling
Collect additional attributes after a successful login, for example first-time capture of phone_number or address.

Profile Enrichment
Augment the profile by calling a third-party API after login, for example a CRM or marketing platform.

Example: redirect for missing phone number

exports.onExecutePostLogin = async (event, api) => {
  const needsPhone = !event.user.user_metadata?.phone_number;
  if (needsPhone && event.transaction?.protocol === 'oidc-basic-profile') {
    api.redirect.sendUserTo('https://app.example.com/first-run', {
      query: { email: event.user.email }
    });
  }
};

Custom DB script size limit
When using a Custom Database, the combined script size limit is 100 KB. Keep code lean and move heavy logic to APIs.

Section 4: Customization

Auth0’s extensibility features allow developers to inject custom logic and branding into the identity flows. Actions are the modern and recommended approach, superseding the legacy Rules and Hooks systems.

4.1 The Extensibility Hierarchy: Actions vs. Rules vs. Hooks

Understanding the evolution and current state of Auth0’s extensibility is critical.

4.2 Anatomy of an Auth0 Action

An Action is a serverless Node.js function that executes at a specific point (a “trigger”) in an Auth0 flow.

4.3 Email Templates and SMTP Configuration

Templates
Auth0 emails are HTML with Liquid syntax. You can format names and conditional content.

Custom SMTP
Configuring a custom SMTP provider is a separate step.

Section 5: Security and Attack Protection

Auth0 provides a layered suite of security features designed to protect against common identity-related threats.

5.1 Multi-Factor Authentication (MFA)

MFA adds a critical layer of security by requiring users to provide more than one form of verification.

A crucial point for the exam is the order of precedence for security policies. MFA behavior defined within a Post-Login Action using methods like api.multifactor.enable() will always override the global tenant-level MFA policy setting. For example, if the tenant policy is set to “Never,” but an Action requires MFA for users with an “admin” role, those admin users will be prompted for MFA.

Understanding the Three Factors of Authentication

Multi-Factor Authentication (MFA) is grounded in the principle of combining distinct categories of authentication factors to enhance security posture. These factors fall into three core domains:

Auth0’s MFA implementation supports a wide array of factors across these domains. For example:

The strength of MFA lies in requiring at least two factors from different categories, significantly increasing resistance to account compromise. For instance, even if a password is leaked (Knowledge), access is denied without the second factor (e.g., OTP or biometric).

This triad forms the conceptual backbone of MFA and is essential for understanding both the security rationale and implementation strategy behind Auth0’s MFA features.

5.2 Attack Protection Suite

Auth0’s Attack Protection features are designed to automatically detect and mitigate various automated and targeted attacks.

5.3 Mitigating Core Web Threats

Auth0 provides built-in mechanisms to defend against fundamental web application attacks.

5.4 Step-Up Authentication and Adaptive MFA

Step-Up Authentication

Adaptive MFA

Step-Up vs Adaptive MFA - quick view

Feature Step-Up Adaptive MFA
Trigger Accessing a sensitive resource Detected risk at login
Timing Post-login During login
Use case API or high-value page access Smart MFA prompts
Key signal Resource sensitivity Risk score (device, IP, travel)

Dashboard quick steps

Action snippet for Step-Up by scope

exports.onExecutePostLogin = async (event, api) => {
  const needsHighValue = (event.authorization?.requested_permissions || []).some(p =>
    ['view:balance', 'transfer:funds'].includes(p)
  );
  const hasMfa = (event.authentication?.methods || []).some(m => m.name === 'mfa') 
                 || (event.user.multifactor && event.user.multifactor.length > 0);

  if (needsHighValue && !hasMfa) {
    api.multifactor.enable('any');
    // Optionally short-circuit issuing the high-value scopes until MFA is completed
    api.accessToken.setCustomClaim('https://example.com/high_value_pending', true);
  }
};

5.5 Assurance Levels and Phishing Resistance (Passkeys)

Authentication Assurance Levels (AAL)

Level Description Example factors
AAL1 Basic single factor Password only
AAL2 Two factors, not necessarily phishing resistant Password + OTP
AAL3 Requires phishing-resistant factor WebAuthn, FIDO security key

Passkeys and FIDO2/WebAuthn

Passkey policies

5.6 WebAuthn (FIDO2)

Concept Explanation
Definition WebAuthn (Web Authentication API) is a W3C standard that allows users to authenticate using public key cryptography rather than passwords. It forms part of the FIDO2 standard (a collaboration between the FIDO Alliance and W3C).
Purpose Provides strong, phishing-resistant authentication using hardware or built-in authenticators such as YubiKey, Windows Hello, Touch ID, or Face ID. It removes dependence on shared secrets and enables both passwordless and MFA experiences.
How It Works 1. Registration: The browser and authenticator generate a key pair. The public key is sent to Auth0 and stored in the user’s profile; the private key never leaves the device.
2. Authentication: Auth0 sends a challenge to the browser, the authenticator signs it with the private key, and Auth0 verifies the signature using the stored public key.
Security Model Each credential is bound to the combination of user + device + origin, preventing phishing and replay attacks. Because the private key never leaves the authenticator, it cannot be stolen or reused elsewhere.
Supported Authenticators - Platform authenticators: built into the device (e.g. Windows Hello, Touch ID).
- Roaming authenticators: external devices (e.g. YubiKey, Titan Key).
Auth0 Integration - Authentication → MFA → WebAuthn (FIDO2): used as a second factor after password login.
- Authentication → Passwordless → WebAuthn: used as a primary passwordless method.
- Can also be triggered through Actions or Step-Up MFA policies for sensitive resources.
Relation to AALs WebAuthn authenticators are considered phishing-resistant and can satisfy AAL3 when used as a factor.

5.6.1 Behaviour on First Login and New Devices

Tip: Think of WebAuthn credentials as keys tied to devices, not accounts. Each trusted device must enrol its own key.

5.6.2 Summary Table

Mode Prompt Timing Purpose Example
Passwordless WebAuthn Prompted first, replaces password Passwordless login “Touch your security key to sign in.”
MFA WebAuthn Prompted after password Second factor (AAL2/AAL3) “Enter password → Touch your key.”
New Device / First Use Not auto-prompted before authentication Must enrol a new credential after identity is verified Register device key after first login.

Key takeaways

Section 6: Monitoring and Logging

6.1 Interpreting Auth0 Logs

Auth0 provides detailed logs for all tenant activity, which are essential for monitoring, troubleshooting, and security analysis.

Section 7: Auth0 Management API

7.1 Automating with the Management API

The Management API (v2) is a RESTful API that enables programmatic control over nearly all aspects of an Auth0 tenant.

Retry guidance

7.2 Naming convention

7.3 High-yield areas and supported verbs

(Paths shown without the required /api/v2 prefix.)

Area Path fragment Supported verbs Notes
Users, collection /users GET, POST List or search users. Create requires connection.
User, single /users/{id} GET, PATCH, DELETE Read, update, or delete a user by ID.
User roles /users/{id}/roles GET, POST, DELETE Manage roles for a user.
User permissions /users/{id}/permissions GET, POST, DELETE Manage direct permissions for a user.
Roles, collection /roles GET, POST List or create roles.
Role relationships /roles/{id}/permissions GET, POST, DELETE List, add, or remove permissions on a role.
Role reverse lookup /roles/{id}/users GET List users who have a given role.
Organisations, members /organizations/{id}/members GET, POST, DELETE List, add, or remove members.
Org member roles /organizations/{id}/members/{user_id}/roles GET, POST, DELETE Manage roles scoped to an organisation.
Jobs, bulk export /jobs/users-exports POST Start a bulk user export job.
Jobs, bulk import /jobs/users-imports POST Start a bulk user import job.
Jobs, status & errors /jobs/{id} · /jobs/{id}/errors GET Poll job completion or fetch errors.
Tickets /tickets/email-verification · /tickets/password-change POST Generate verification or password-reset URLs.
Attack protection /user-blocks/{id} GET, DELETE Read or clear brute-force blocks for a user ID.

7.4 Quick heuristics

8. Auth0 CLI

The Auth0 CLI lets you manage tenant resources from your terminal for quick, interactive tasks. Use the Deploy CLI when you need configuration as code.

8.1 Install and login

8.2 Everyday commands

8.3 Deploy CLI, when you need config as code

8.4 Exam cues

References:

Part II: Practical Application and Hands-On Task Preparation

This section provides practical, step-by-step guides for the hands-on use cases that are assessed in Part II of the Okta Certified Developer - Auth0 exam. Each guide is designed to be a concise lab, walking through the necessary configurations in the Auth0 Dashboard and explaining the core concepts involved.

Task 1: Authentication

This set of tasks focuses on configuring various methods for user authentication.

1.1 Set up Single Sign-On (SSO)

Configure a SAML SSO Integration (Auth0 as IdP)

Follow the codelab here:
Configure Database and Passwordless Connections in Auth0

1.2 Implement Passwordless Authentication

This lab demonstrates how to set up passwordless login using an email magic link.

Follow the codelab here:
Configure Database and Passwordless Connections in Auth0

What you’ll practice:

1.3 Create Custom Database

This lab shows how to connect Auth0 to an external, legacy user database.

Detailed guide: Create Custom Database Connections

Steps in the Auth0 Dashboard

  1. Create a new database connection
    • Go to Dashboard → Authentication → Database.
    • Click Create DB Connection.
    • Enter a Name (alphanumeric + dashes, ≤ 35 chars).
    • Optional settings:
      • Requires Username → users must register with both username + email.
      • Username Length → set min/max lengths.
      • Disable Signups → block self-service signup; only admins can create users.
    • Click Create.
  2. Enable custom database
    • Open the new connection.
    • Go to the Custom Database tab.
    • Toggle Use my own database → ON.
  3. Create action scripts
    • Required: Login script.
      • Authenticates the user against your DB.
      • Must return a user object with unique id (prefix with connection name to avoid collisions).
    • Optional:
      • Create (signup new users).
      • Verify (post-email verification).
      • Change Password.
      • Get User (retrieve profile by email).
      • Delete (remove user).
    • Use Templates dropdown (MySQL, PostgreSQL, MongoDB, etc.) to scaffold code.
    • Modify with your DB details (host, username, password, schema).

    • Example (MySQL login):

      function login(email, password, callback) {
  var bcrypt = require('bcrypt');
  var mysql = require('mysql');
  var connection = mysql.createConnection({
    host: 'localhost',
    user: 'me',
    password: 'secret',
    database: 'mydb'
  });
  connection.connect();
  connection.query(
    "SELECT id, nickname, email, password FROM users WHERE email = ?",
    [email],
    function (err, results) {
      if (err || results.length === 0) 
        return callback(new WrongUsernameOrPasswordError(email));
      var user = results[0];
      bcrypt.compare(password, user.password, function (err, isValid) {
        if (err || !isValid) return callback(new WrongUsernameOrPasswordError(email));
        return callback(null, {
          id: 'MyConnection|' + user.id.toString(),
          nickname: user.nickname,
          email: user.email
        });
      });
    }
  );
}
    • Click Save and Try to test the script.
  4. Attach connection to apps
    • Go to the Applications tab of the connection.
    • Enable it for your target app(s).

✅ At this point, Auth0 will call your scripts whenever users authenticate, sign up, reset password, or are managed in your legacy database.

1.4 Set up Social Connections

This lab demonstrates how to configure social logins (e.g., Google, Facebook, GitHub) in Auth0.

Follow the codelab here:
Configure Connections in Auth0

What you’ll practice:

Task 2: Managing Users

These tasks focus on user data management, including migration and authorization.

2.1 Implement Bulk User Migration

This section explains how to bulk migrate users into Auth0. You can do this in the Dashboard or via the Management API.

Docs: Bulk User Imports

Prerequisites

Option A — Dashboard: Bulk import via UI

  1. Open Users: In the Auth0 Dashboard, go to User Management → Users.
  2. Start Import:
    • If your tenant has no users yet, click Import Users.
    • If users exist, choose Import/Export Users → Import Users.
  3. Upload file: Select your users JSON file, making sure it follows the import schema.
  4. Choose destination connection: Pick the Database Connection to import into.
  5. Run the import: Submit the job and wait for completion.
  6. Verify: Once complete, spot-check a few imported users and perform a test login.

Notes for the UI path

Option B — Management API: Bulk import job

  1. Prepare JSON: Build a users JSON file that follows the Bulk Import schema.
  2. Pick connection: Identify the connection_id of your destination database connection.
  3. Create job: Call POST /api/v2/jobs/users-imports with multipart form data:
    • users = your JSON file
    • connection_id = target database connection
    • Optional flags like upsert and send_completion_email
  4. Poll job status: Use the returned job_id to check progress until it completes.
  5. Verify and test: Spot-check imported users and perform a test login.

After import

Tips and gotchas

2.2 Set up Organizations and Access Control/Roles

This lab demonstrates how to configure Organizations in Auth0 to manage B2B users and apps, including setting up roles and access control.

Follow the codelab here:
Manage B2B Users and Apps with Auth0 Organizations

2.3 Enrich Tokens (Custom Claims)

This lab demonstrates adding a custom claim to a token using an Action.

  1. Add Metadata to a User: Navigate to User Management > Users and select a test user. In the “Metadata” section, under app_metadata, add the following JSON: {"plan": "premium"}. Save the changes.
  2. Create a Post-Login Action: Navigate to Actions > Library and create a new “Login / Post Login” action from scratch. Name it “Add Plan Claim”.
  3. Write the Action Code: In the editor, add the following code to read the metadata and add it as a custom claim to both the ID and Access Tokens. The claim must be namespaced. 
    exports.onExecutePostLogin \= async (event, api) \=\> {  
  const namespace \= 'https://myapp.example.com/';  
  if (event.user.app\_metadata.plan) {  
    api.idToken.setCustomClaim(\`${namespace}plan\`, event.user.app\_metadata.plan);  
    api.accessToken.setCustomClaim(\`${namespace}plan\`, event.user.app\_metadata.plan);  
  }  
};
  4. Deploy and Attach: Deploy the Action and drag it into the Login flow. Click Apply.
  5. Verify: Log in as the test user and obtain an ID or Access Token. Decode it and verify that it now contains the claim https://myapp.example.com/plan: “premium”.

Task 3: Customization

These tasks cover customizing the appearance and behavior of the Auth0 platform.

3.1 Set up Branding

This lab demonstrates how to customize the Universal Login page with your own branding.

Follow the codelab here:
Customize Auth0 Universal Login

3.2 Create Custom Actions

This lab shows how to extend Auth0 with Actions, adding custom logic to the authentication pipeline.

Follow the codelab here:
Working with Actions

Task 4: Security

This task focuses on enhancing security by enabling Multi-Factor Authentication.

4.1 Set up Multi-Factor Authentication

This lab covers enabling and configuring MFA to secure user logins.

Follow the codelab here:
Secure Auth0 Applications with MFA

Part III: Useful Documentation

Applications and App Types

Authentication, Protocols, and Flows

Tokens and JWT

Logout and Single Sign-on

Universal Login and Identifiers

Organizations and Multi-tenant

Actions, Rules, Hooks, and Triggers

Multi-factor Authentication

Attack Protection and Security

Monitoring and Logs

APIs and Management API

Tutorials and Overviews

Exam Resources

Third-party explainers and blogs