Okta Certified Consultant cheat sheet

Okta org tiers determine available features: Developer (free, limited MAU, no production support), Enterprise, and Customer Identity (CIAM) editions differ in authentication policies, MFA factors, and integration support.

The Okta Integration Network (OIN) provides pre-built SAML/OIDC app templates; for custom apps use the App Integration Wizard with SAML 2.0 or OpenID Connect, setting ACS URL, Entity ID, and attribute statements.

For on-premises Active Directory integration, install the Okta AD Agent on a domain-joined Windows server; it creates an agent connection (outbound only, port 443) and enables delegated authentication, password sync, and user import.

Okta LDAP Agent supports generic LDAP directories (e.g., OpenLDAP, Sun Directory) for authentication and profile sync; it does not support password write-back to the directory.

For HR-driven provisioning use Okta Lifecycle Management with OIN apps (Workday, SuccessFactors, BambooHR) or SCIM 2.0 for custom HR systems; import rules map HR attributes to Okta profile and trigger downstream app assignments.

Universal Directory allows custom attributes on user profiles; define them in Profile Editor, set data type and permissions (read/write, admin only), and reference them in app attribute statements and group rules.

Group rules evaluate user attributes to assign group membership dynamically; rules run on user creation/update and can be previewed; they do not remove users from groups if the rule is deleted-manual cleanup is required.

Network zones define IP ranges for policy conditions (e.g., corporate IPs, blocklists); zones are referenced in sign-on policies, MFA policies, and app authentication policies to enforce context-based access.

Okta supports multiple identity providers (IdPs) for inbound federation: configure a SAML or OIDC IdP in Okta, map attributes, and use routing rules or IdP discovery to direct users to the correct IdP.

SAML 2.0 integration requires: IdP metadata (Okta) uploaded to SP, SP metadata (ACS URL, Entity ID) configured in Okta, and attribute statements mapping Okta profile fields to SP-expected attributes (e.g., email, firstName).

OIDC integration uses authorization code flow with PKCE for web/native apps; configure redirect URIs, grant types, and scopes in Okta; tokens include ID token (user info) and access token (API authorization).

SCIM 2.0 provisioning: Okta supports SCIM 1.1 and 2.0 for user/group lifecycle; configure the SCIM connector base URL, authentication (OAuth bearer token or Basic), and attribute mappings in the app's Provisioning tab.

For Office 365 integration, Okta uses WS-Federation or SAML 2.0; configure domain federation in Azure AD, set immutable ID to Okta user ID, and enable provisioning for licenses and groups.

RADIUS agent enables Okta MFA for VPN and network devices; install the Okta RADIUS Server Agent, configure the agent for the Okta org, and set the network device to use RADIUS with Okta as the authentication server.

Okta Access Gateway (OAG) publishes on-premises web apps (header-based or Kerberos) through Okta; configure the OAG host, join to Okta org, and define app routes with protected resources and policies.

Workflows (Okta Workflows) automate identity processes: use connectors to apps, triggers (user created, group added), and functions (HTTP, approval, assign app) to build no-code flows; test with run history and versioning.

For API access management, create an authorization server (default or custom), define scopes and claims, and use OAuth 2.0 client credentials or authorization code flow; access tokens are JWTs validated by resource servers.

Okta Verify with Push is a common MFA integration; enroll users via policy, configure push notification (Okta Verify) and number challenge; for FIDO2/WebAuthn use security keys or platform authenticators.

Authentication policies (app-level) vs. global session policy: global session policy determines IdP session lifetime and MFA enrollment; app authentication policies control access to individual apps and can re-prompt for MFA.

Policy evaluation order: Okta evaluates global session policy first (sign-on), then app authentication policies; rules are evaluated top-down, first match wins; use 'Catch-all' rule as default.

For delegated authentication with AD, configure the AD agent for delegated authentication, enable 'Authentication' in the directory settings, and set the agent to use Kerberos or NTLM; password is validated by AD, not Okta.

Profile mastering: define source priority (Okta, AD, HR) per attribute in Profile Editor; lower priority sources cannot overwrite higher priority values; use 'Okta as source' for attributes managed only in Okta.

Group membership can be sourced from AD (via import), Okta group rules, or app groups; for AD-sourced groups, changes in AD sync to Okta; Okta group rules do not apply to AD-sourced groups unless configured.

MFA enrollment policy: set 'Required' vs 'Optional' at global session policy level; use authenticator enrollment policy to define which factors are available and their order; FIDO2/WebAuthn requires HTTPS and compatible browsers.

For inbound SAML federation, configure IdP discovery (routing rules) based on email domain or IP; use the Okta Sign-In Widget with idpDiscovery parameter; routing rules are evaluated in order.

App sign-on modes: SAML 2.0, WS-Federation, OIDC, SWA (password vaulting), and bookmark-only; SWA uses browser plugin or Okta Access Gateway for form-based apps; bookmark-only provides a link without SSO.

Rate limits: Okta enforces API rate limits per org (e.g., 600 requests/min for GET /api/v1/users); use exponential backoff and monitor the X-Rate-Limit-Remaining header; bulk operations may require batching.

Okta APIs: Core API (users, groups, apps) at /api/v1; use API tokens (generated in Security > API) with SSWS Authorization header; tokens inherit the permissions of the admin who created them.

For user lifecycle, use the /api/v1/users endpoint with activate, deactivate, suspend, unsuspend, and reset password operations; status transitions follow: STAGED → ACTIVE → SUSPENDED → DEPROVISIONED.

Okta Expression Language (EL) is used in attribute statements, group rules, and policy conditions; syntax: ${user.firstName}, ${user.getGroups()}, string functions like ${String.toUpperCase(user.email)}; test in Expression Editor.

SAML attribute statements support EL; use NameFormat (unspecified, emailAddress, URI) and map to SP-required names; for OIDC claims, configure in authorization server claims or app profile mappings.

Okta System Log provides audit events; query via API /api/v1/logs with filters (since, until, filter=eventType eq "user.session.start"); export to SIEM via OIN (Splunk, Sumo Logic) or Log Streaming (Amazon EventBridge).

For troubleshooting SAML, use the Okta SAML Tracer (browser extension) or the SP's SAML debug tools; verify: AuthnRequest, SAMLResponse signature, audience restriction, recipient, and time skew (clock skew tolerance typically 5 minutes).

Okta Verify enrollment: use the /api/v1/users/{id}/factors endpoint to enroll factors programmatically; for push, the user must have Okta Verify installed; for TOTP, generate a shared secret and QR code.

Okta Workflows uses a visual builder with cards; connectors include Okta, HTTP, Slack, and Google; use 'Okta - List Users' and 'Okta - Assign User to App' for automation; test flows with 'Test Run' and monitor execution history.

For high availability, deploy multiple AD agents (at least two per domain) and configure load balancing; Okta orgs are multi-tenant SaaS with 99.99% uptime SLA for Enterprise; use preview orgs for testing before production.