Okta Certified Developer cheat sheet

Every Okta management API call authenticates with either an API token (SSWS scheme in the Authorization header) or an OAuth 2.0 access token; the SSWS token inherits the permissions of the admin who created it and is sent as 'Authorization: SSWS '.

Core API base URL is https://{yourOktaDomain}/api/v1; the org authorization server is https://{yourOktaDomain}/oauth2/v1/token, while a custom authorization server is https://{yourOktaDomain}/oauth2/{authServerId}/v1/token.

Okta enforces rate limits per endpoint and per org; responses include X-Rate-Limit-Limit, X-Rate-Limit-Remaining, and X-Rate-Limit-Reset (epoch seconds). Exceeding the limit returns HTTP 429 with errorCode E0000047.

Pagination uses the Link header with rel="next"; the cursor is opaque, so follow the URL rather than constructing one. Management endpoints cap results with the 'limit' query parameter (default 200 for most collections).

Okta SDKs (Java, .NET, Node, Python, Go, PHP, Ruby) wrap the same REST API; each client is constructed from the org URL plus an API token or OAuth private-key JWT credentials, and most expose typed models plus a raw request escape hatch.

Errors return a JSON body with errorCode, errorSummary, errorCauses, and errorLink. E0000001 is a general validation failure, E0000007 is resource not found, E0000011 is an invalid token, and E0000004 is an authentication failure.

The Okta Expression Language is used in profile mappings, group rules, and claim expressions; it supports user, group, and app attributes plus functions such as String.substringBefore and isMemberOfGroupName.

Event and System Log queries use GET /api/v1/logs with filters like 'filter=eventType eq "user.session.start"' and 'since=' timestamps; results are retained for 90 days and can be streamed to external SIEMs.

Authorization Code with PKCE is the required flow for single-page and native apps because they cannot protect a client secret; Okta rejects token requests without a code_verifier when PKCE is configured.

The Org Authorization Server issues tokens only for Okta-managed APIs and cannot customize scopes or claims; to add custom scopes or claims, use a Custom Authorization Server (access policy + rules).

ID tokens are OIDC JWTs that prove authentication and carry claims such as sub, iss, aud, exp, iat; access tokens authorize API calls and are validated by the resource server, not the client.

Token validation requires checking the signature against the JWKS endpoint (/{authServer}/v1/keys), plus iss, aud, and exp. The 'kid' header selects the correct key.

Refresh tokens are only issued when the 'offline_access' scope is requested and the app is configured to allow refresh; rotating refresh tokens issue a new refresh token on each use.

Client authentication methods include client_secret_basic, client_secret_post, client_secret_jwt, and private_key_jwt; private_key_jwt signs an assertion with the app's registered public key and avoids shared secrets.

MFA is enforced through authenticators (Okta Verify, WebAuthn, TOTP, SMS, email) and authentication policies; the Factors API enrolls and verifies factors under /api/v1/users/{id}/factors.

The /oauth2/v1/introspect endpoint validates an opaque or JWT token server-side and returns 'active: true/false'; use it when the resource server cannot verify signatures locally.

SAML 2.0 apps require the IdP metadata (entity ID, SSO URL, signing certificate) and the SP ACS URL plus audience URI; Okta signs assertions by default and can optionally sign the response.

OIDC app integrations in Okta are configured with redirect URIs, grant types, and either a client secret or public key; the 'Login redirect URIs' must match exactly, including trailing slashes.

The App Embed Link (bookmark URL) and the /app/{appName}/{appId}/sso/saml endpoint let you launch SSO directly; IdP-initiated flows start at Okta, SP-initiated flows start at the app.

SCIM 2.0 provisioning is configured under the app's Provisioning tab; Okta supports create, update, and deactivate operations against /Users and /Groups, and requires a unique externalId mapping.

Attribute statements map Okta user profile attributes to SAML assertion attributes, while group attribute statements filter which groups are sent (by name, prefix, or regex).

Sign-on policies attach to apps or groups and define rules for MFA, session lifetime, and re-authentication; they evaluate top-down and the first matching rule applies.

For OIDC apps, the 'groups' claim must be explicitly added in the custom authorization server claim configuration; it is not included by default.

Okta supports SWA (Secure Web Authentication) for apps without federation, storing credentials for browser-plugin or app-plugin autofill; it is not true SSO and does not issue tokens.

User lifecycle states include STAGED, PROVISIONED, ACTIVE, RECOVERY, LOCKED_OUT, PASSWORD_EXPIRED, SUSPENDED, and DEPROVISIONED; transitions use dedicated endpoints such as /lifecycle/activate, /lifecycle/suspend, and /lifecycle/deactivate.

A user is created via POST /api/v1/users with a profile object and optional credentials; setting 'activate' as a query parameter activates immediately, otherwise the user stays STAGED.

Group rules (expression-based) and group membership APIs assign users dynamically; rules run asynchronously and can take minutes to apply after a profile change.

Profile mastering can be Okta (default) or an external source (e.g., AD, HR system); when external, Okta profile edits may be overwritten on the next import.

Bulk operations use the /api/v1/users/{id}/lifecycle endpoints individually, or the Users API with pagination; Okta also supports CSV import via the admin console rather than a public bulk API.

Password policies define length, complexity, history, and lockout; the /api/v1/users/{id}/credentials/change_password endpoint changes a password and requires the old password for self-service.

Deprovisioning via SCIM sends a deactivate (PATCH active=false) or DELETE; Okta marks the app user inactive but retains the Okta user record unless the Okta user is deactivated.

User profile mappings connect Okta attributes to app attributes; the 'Okta to App' direction pushes data during provisioning, while 'App to Okta' imports on sign-in or import runs.