Okta Certified Professional cheat sheet

Okta user statuses include STAGED, PROVISIONED, ACTIVE, RECOVERY, LOCKED_OUT, PASSWORD_EXPIRED, SUSPENDED, and DEPROVISIONED; only ACTIVE users can authenticate, and SUSPENDED users keep their profile and group memberships while DEPROVISIONED users do not.

A user can belong to many groups; group membership drives application assignment, group-based policy evaluation, and admin role scoping. Groups have two types: OKTA_GROUP (managed in Okta) and APP_GROUP (imported from an app via profile sourcing or group push).

Universal Directory profile attributes can be Okta-defined, custom, or app-sourced. Attribute-level mastering controls which source wins on conflict; app-sourced attributes are read-only in Okta unless the app is the master.

Profile sourcing (import) pulls user attributes from an app into Okta; group push sends Okta groups and memberships out to an app. Both require an app that supports the feature and a configured provisioning connection.

Bulk operations include CSV import (create/update users) and bulk deactivation; CSV import requires unique login values and reports per-row errors rather than rolling back the whole file.

Password policies control minimum/maximum length, complexity, history count, lockout duration, and session idle timeout; they are assigned by group priority, and the first matching policy applies.

MFA enrollment policies determine which factors a user may or must enroll, and can be scoped to a group with an optional enrollment grace period before enforcement.

User deactivation removes app assignments and active sessions; reactivation restores the profile and group memberships, but app-side accounts may need reprovisioning depending on the app's deprovisioning settings.

Admin roles (Super Admin, Org Admin, Group Admin, Help Desk Admin, Read-Only Admin, App Admin) are scoped by resource; Group Admin and Help Desk Admin are limited to assigned groups and permitted actions.

SAML 2.0 flow: Okta (IdP) signs a SAML assertion containing NameID and attribute statements; the SP validates the signature against the IdP certificate, then creates its own session. Clock skew and expired certificates are the most common failure causes.

OIDC flow: Okta acts as OpenID Provider; the app receives an ID token (JWT) plus access token. The ID token's iss, aud, exp, and nonce must be validated, and signing keys are fetched from the org's JWKS endpoint.

WS-Federation uses a similar trust model to SAML but with a different message format; Okta supports it for Microsoft-centric applications.

SWA (Secure Web Password) is a password-replay SSO mode for apps without federation support; Okta stores credentials and submits the login form. SWA does not support MFA at the app and requires the Okta Browser Plugin for some flows.

SAML attribute statements map Okta profile attributes to app-side attributes; the NameID format (for example, unspecified, emailAddress, persistent) must match what the SP expects.

The IdP-initiated flow starts at the Okta dashboard; SP-initiated starts at the app, which redirects to Okta. SP-initiated requires correct ACS URL and Audience URI values in the Okta app configuration.

Sign-on policies (Okta sign-on policy and app sign-on policy) evaluate rules top-down by priority; the first matching rule determines authentication requirements such as MFA, session lifetime, and access denial.

Okta's Access Gateway and app-level policy can extend SSO to on-premises apps; the app's Sign On tab defines the SSO mode (SAML, OIDC, SWA, bookmark-only).

Bookmark apps provide a dashboard link without credential replay or federation; they are used for apps where SSO integration is not configured.

The org's Global Session Policy sets session lifetime and idle timeout and can require MFA for all users; the Authentication Policy (Okta sign-on policy) applies per-app or org-wide rules with conditions on network zone, device, and risk.

Network zones define IP ranges (CIDR) or geolocations; they can be blocklisted or allowlisted and are referenced as conditions in sign-on and MFA policies.

MFA factor types include Okta Verify (push, TOTP, FastPass), SMS, voice, email, security question, WebAuthn, YubiKey OTP, and TOTP authenticators. Factors can be set as required, optional, or disabled per policy.

The Authenticators page controls org-wide factor availability; per-policy settings then determine enforcement. Disabling an authenticator affects users who rely on it, so factor coverage must be checked first.

Password policy settings include lockout (number of attempts and duration), password history, and session idle timeout; lockout thresholds are per-policy and apply to the users assigned to that policy.

API tokens inherit the permissions of the admin who created them and are shown only once; they should be rotated and scoped to least privilege. OAuth 2.0 service apps are preferred for automation.

System Log entries record actor, target, outcome, and event type; they can be streamed to a SIEM via Log Streaming and exported for retention. Admin access and MFA changes are auditable there.

ThreatInsight uses Okta's network to flag suspicious sign-in behavior; behavior detection and risk-based rules can trigger step-up authentication.

The org's security settings include the ability to require MFA for admin console access, restrict admin sessions, and set the Okta Support access duration.