Skip to main content
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 agent-svc@yourcompany.com.
2

Enable Google Authenticator

Go to Security then Authenticators, click Add authenticator, and add Google Authenticator. It registers as a possession factor.Okta Authenticators page with the Add authenticator button marked and Google Authenticator listed as activeOn 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.Okta Google Authenticator enrollment screen with the Can't scan link markedCopy 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.
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.
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:
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

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.
Agent signing in to Okta: username, Google Authenticator code, password, then the dashboard

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.