Okta, Step by Step

These steps were followed and verified end to end. Menu names come from the current Okta admin console. If you have not read Single Sign On yet, start there — it explains why a dedicated account is needed and what Test access does.

​

1. Create the application

Applications → Applications → Create App Integration

• Sign-in method: OIDC - OpenID Connect
• Application type: Web Application
• Grant type: Authorization Code
• Sign-in redirect URI: your site’s callback address
• Save, then copy the Client ID and Client secret from the General tab

​

2. Create the service account

Directory → People → Add Person Ticking I will set password is not optional. Left unticked, Okta creates the account with no password and emails an activation link, and the agent has no inbox. When you tick it, two more controls appear. Set a password, and untick “User must change password on first sign-in”.

​

3. Create a group

Directory → Groups → Add group, name it something like superflow-agents, and add the service account to it. The group exists so the three policy rules below have something to point at. You do not need it for application access.

​

4. The three policies

All three target the superflow-agents group. All three are needed.

​

a. Application sign on policy

From the app’s Sign On tab, scroll past the token settings to the authentication policy card, and open the policy it names. Or go to Security → Authentication Policies and pick the policy your app uses. Add a rule:

• IF User’s group membership includes → superflow-agents
• THEN Access is Allowed, and User must authenticate with a single factor option such as Password / IdP

Avoid any option containing “2 factor types” or ”+ Another factor”. Okta warns that single factor rules are weak and makes you click Save anyway. That warning is correct in general and expected here: this rule applies only to one non-human account. New rules are placed above the Catch-all rule automatically. The Catch-all is pinned last and cannot be moved.

​

b. Global session policy

Security → Global Session Policy → add a policy or rule for superflow-agents with Multifactor authentication: Not required, placed above the default. This is separate from the first and neither substitutes for the other. One governs opening the application, the other governs establishing a session with Okta at all.

​

c. Authenticator enrolment

Security → Authenticators → Enrollment → add a policy for superflow-agents with Password required and the authenticator apps set to Optional or Disabled, placed above the default. You may find that Email cannot be set to Optional and has to be Disabled. Okta rejects Optional when the email authenticator is configured for recovery only, because Optional and Required both need it enabled for authentication. Disabled is the better choice here anyway, since it removes one more enrolment prompt.

​

5. Prove it before involving an agent

Open a private browser window and sign in to your protected page by hand, as the service account. If you reach your content having typed only a username and password, with no code prompt, no enrolment screen, and no password change, then the agent will get in too. If any extra screen appears, that is the policy still to fix, and you have found it in thirty seconds instead of a full agent run.

​

6. Connect it in Superflow

Enter the service account’s username and password in Site Access, choose Single sign on, and press Test access. Because okta.com is a recognised provider, it signs in directly without asking you to confirm the address.