Sign in to Okta with MFA

Let an agent clear an Okta MFA challenge using a TOTP secret stored in a Vault

AI agent instructions

Read the Notte skill and follow its setup instructions when setting up Notte or building browser automation. This is the shared source for CLI setup, authentication, and the browser-to-code workflow.

An agent can complete an Okta sign-in end to end, including the MFA step, when the second factor is a TOTP authenticator. You store the TOTP secret in a Vault and Notte generates the one-time code at the moment the challenge appears.

Okta Verify push cannot be automated. Approval happens on an enrolled physical device, and the enrollment QR carries a one-time activation token rather than a shared secret. Use a TOTP authenticator instead, as described below.

Prerequisites

• Admin access to your Okta org
• The Notte CLI installed and authenticated with notte auth login
• A coding assistant such as Claude Code, with the Notte skill installed via notte skill add

Use a dedicated service account rather than a person’s identity. A TOTP secret is equivalent to the factor itself, so anyone holding it can pass the challenge. Grant the account only the app access the automation needs.

Set up the Okta side

1. Create a service account

   In the Okta Admin Console, go to Directory then People and add a user for the automation, for example [e-mail].

2. Enable Google Authenticator

   Go to Security then Authenticators, click Add authenticator, and add Google Authenticator. It registers as a possession factor.

   

   On the Enrollment tab, set Google Authenticator to Optional or Required for the group your service account belongs to.

   Check Security then Authentication Policies too. If the rule protecting your app requires a phishing-resistant or device-bound factor, Okta rejects TOTP and keeps asking for Okta Verify. The rule has to accept any possession factor. This is the step most likely to block you.

3. Enroll and reveal the secret

   Sign in as the service account, open its end-user settings, and set up Google Authenticator. On the QR screen, click Can’t scan? to reveal the base32 secret.

   

   Copy that value. It is the mfa-secret in the next step.

   Okta Verify shows a QR too, but it encodes an oktaverify:// activation URL with no secret in it. Only a TOTP authenticator gives you a reusable seed.

Set up the Notte side

1. Store the credentials in a Vault

   Create a vault and add the Okta credentials. Keep the vault_id it returns.

   notte vaults create
   
   notte vaults credentials add \
     --vault-id <vault-id> \
     --url "https://<your-org>.okta.com" \
     --email "[e-mail]" \
     --password "<password>" \
     --mfa-secret "<base32-secret>"
   

   Credentials are encrypted at rest and never reach the model. Notte substitutes the real values into the page only at fill time, and generates the one-time code from the stored secret.

2. Start a session

   Create a profile so the signed-in state can be saved, then start a session with both attached.

   notte profiles create
   
   notte sessions start -y \
     --vault-id <vault-id> \
     --profile-id <profile-id> \
     --profile-persist
   

   Pass -y. Without it the CLI can stop on a confirmation prompt when another session is already running, and in a non-interactive shell the session still starts but your flags are dropped, leaving you with no vault and no profile.

3. Let your coding assistant drive the sign-in

   With the Notte CLI and skill installed, ask Claude Code to walk the flow in plain language:

   Using the notte CLI on session <session-id>, sign in to https://<your-org>.okta.com.
   The credentials are in the attached vault. If Okta offers a choice of security method,
   choose Google Authenticator, not Okta Verify. Observe the page after each step and stop
   when the Okta dashboard has loaded.
   

   It drives the browser with notte page goto, notte page observe, notte page click and notte page fill, checking the page between actions. See Claude Code & AI Agents for the full loop.

4. Confirm it worked

   notte page observe --session-id <session-id>
   

   A successful sign-in lands on /app/UserHome. You can also download the recording with notte sessions replay --session-id <session-id>.

Result

The agent fills the username, picks Google Authenticator from the security method list, enters a code generated from the stored secret, submits the password, and lands on the dashboard. No device and no person in the loop.

Session replay at 8x speed. Account identifiers are masked.

Because the assistant reads the page before each action, it follows whatever order your org uses. The run above asks for the factor before the password, which is an Okta policy choice rather than a fixed sequence, and a hardcoded script would break on it.

Reuse the signed-in state

With --profile-persist, the browser state is written back when the session closes, so the Okta domain carries its cookies into the next session that attaches the same profile. See Browser Profiles for how to reuse and refresh that state.