Hi Okta team,
We’re building a CDP integration (Oneprofile) that reads Users, Groups, and Apps from customers’ Okta orgs via the core API — the OIN “API service integration” (OAuth 2.0 client-credentials, service-to-service) model. We provisioned an Integrator Free Plan org (integrator-4344084.okta.com, admin username team@oneprofile-integrations.com) to build and test against.
The blocker: on first admin sign-in the org’s global sign-on policy forces enrollment of Okta Verify as the only allowed factor. Our build/test environment is automated/headless and can’t enroll a push-based mobile authenticator. The “Can’t scan?” flow only offers “Email me a setup link” / “Text me a setup link”, and both just open in the Okta Verify mobile app — there’s no TOTP (Google Authenticator), email OTP, or WebAuthn fallback.
Questions:
1. On the Integrator Free Plan, can I change the org authenticator enrollment / global session (sign-on) policy so admin login can use a standard factor such as TOTP (any RFC 6238 app), email OTP, or a WebAuthn security key instead of Okta Verify? If so, where is that configured, given I can’t currently complete the initial Okta Verify enrollment to reach the Admin Console?
2. Alternatively, is there a developer/technology-partner sandbox for OIN API service integrations that ships with a standard authenticator by default?
Any pointer to the right setting or the OIN technology-partner team would be hugely appreciated. Thanks!
By default, I believe only Email, Okta Verify, and Password are configured, but the other authenticators (such as Google Authenticator, Passkey, RSA SecurId, etc) can be added under Security → Authenticators → Setup by clicking “Add authenticator”
Your Default Policy for enrollment (Security → Authenticators → Enrollment) should have Password set to required and any of the others set to optional (including any authenticators you add), but the authentication policy rules for the admin app (Security → Authentication Policies → App sign-in → Okta Admin Console) still require 2FA.
The AdminApp policy by default will be configured for Password + Okta Verify, but once you add another Possession factor (e.g. Google Authenticator or WebAuthn), it should show up in this rule and admins will be able to login using it
I also consider email verification for default permission. And if there’s anyway the community will support my integration to my app or third party application I will verify all with emails verification for smooth integration I will be very happy.
Thanks so much, Andrea — this is exactly the config detail we needed.
The one catch we’re hitting: your steps (Security → Authenticators → Setup → Add authenticator, and the Okta Admin Console app sign-in policy) all live inside the Admin Console, but on org integrator-4344084 we can’t reach the Admin Console at all. On the very first admin sign-in the org forces Okta Verify enrollment before it will let us in — password is accepted, then it jumps straight to a mandatory “Set up Okta Verify” screen, and “Can’t scan?” only offers “Email me a setup link” / “Text me a setup link” (both open the Okta Verify mobile app). There’s no TOTP/email-OTP/WebAuthn option at that enrollment step and no skip, so we never land on the dashboard to change the enrollment or app-policy settings you described. It’s a bit of a chicken-and-egg: to add a standard authenticator we need in, but to get in we need a standard authenticator.
Two questions:
1. Is there a way to complete that initial admin sign-in with email OTP (or bypass the forced Okta Verify enrollment once) so we can reach the Admin Console and then apply your steps?
2. If not, could the devsupport team adjust the Okta Admin Console app sign-in policy on integrator-4344084 to accept email/password (or add a standard Possession factor) so we can log in the first time?
Happy to provide any org identifiers you need. Really appreciate the help!
At least right now, it looks like you will need to use Okta Verify since its the only factor that is available by default that will meet the requirements for the Admin app.
That said, I will check internally to see if we could look into enabling another authenticator (that meets the user possession requirement) like Passkey/WebAuthn by default so that it can be used for accessing the Admin app instead.
