Okta Certified Developer flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

SSWS authorization header

The scheme used to send an Okta API token: 'Authorization: SSWS <token>'. The token carries the creating admin's permissions and is intended for server-side use only.

Rate limit response code

HTTP 429 with errorCode E0000047 indicates the rate limit was exceeded. Response headers X-Rate-Limit-Remaining and X-Rate-Limit-Reset tell you when to retry.

Link header pagination

Okta returns a Link header with rel="next" containing an opaque cursor URL. Clients should follow that URL rather than constructing pagination parameters manually.

Okta Expression Language

A lightweight expression syntax used in profile mappings, group rules, and claims. It references attributes like user.firstName and supports string, array, and conditional functions.

System Log API

GET /api/v1/logs returns event records filterable by eventType and since. Events are retained for 90 days and are commonly streamed to a SIEM.

Common error codes

E0000007 means resource not found, E0000011 means invalid token, E0000004 means authentication failed, and E0000001 is a general validation error returned in the JSON error body.

PKCE requirement

Proof Key for Code Exchange is mandatory for public clients such as SPAs and mobile apps. The client sends a code_challenge and later a code_verifier to bind the token request.

Org vs custom auth server

The Org Authorization Server issues tokens for Okta APIs and cannot customize scopes or claims. Custom Authorization Servers support custom scopes, claims, and access policies.

ID token vs access token

An ID token is an OIDC JWT proving user authentication with claims like sub and aud. An access token authorizes API calls and is validated by the resource server.

JWKS validation

Resource servers verify JWT signatures against the authorization server's JWKS endpoint, selecting the key by the token header's kid, then check iss, aud, and exp.

offline_access scope

Requesting offline_access causes Okta to issue a refresh token, provided the app is configured to allow it. Without this scope, no refresh token is returned.

private_key_jwt

A client authentication method where the app signs a JWT assertion with its private key. Okta validates it against the registered public key, avoiding shared secrets.

Token introspection

The /oauth2/v1/introspect endpoint checks a token server-side and returns active true or false plus metadata. Useful when the resource server cannot verify signatures locally.

SAML ACS URL

The Assertion Consumer Service URL is the SP endpoint that receives SAML assertions. It must match the value registered in Okta or the assertion is rejected.

OIDC redirect URI matching

Okta requires the redirect_uri in the authorization request to exactly match one registered Login redirect URI, including scheme, host, path, and trailing slash.

SCIM provisioning

SCIM 2.0 lets Okta push user and group create, update, and deactivate operations to an app's /Users and /Groups endpoints using a mapped externalId.

SAML attribute statements

Attribute statements map Okta profile fields to SAML assertion attributes. Group attribute statements filter which groups are included by name, prefix, or regex.

Sign-on policy evaluation

Sign-on policies attach to apps and evaluate rules top-down; the first matching rule determines MFA requirements, session lifetime, and re-authentication behavior.

Groups claim in OIDC

Custom authorization servers do not include groups by default. A claim must be configured with an expression such as Groups.startsWith or a group filter.

SWA apps

Secure Web Authentication stores app credentials for browser or app plugin autofill. It provides credential replay rather than true federation and issues no tokens.

IdP vs SP initiated

IdP-initiated SSO starts at Okta and posts an assertion to the app. SP-initiated SSO starts at the app, redirects to Okta, and returns an assertion to the ACS URL.

User lifecycle states

Okta users move through STAGED, PROVISIONED, ACTIVE, RECOVERY, LOCKED_OUT, PASSWORD_EXPIRED, SUSPENDED, and DEPROVISIONED, each reached via dedicated lifecycle endpoints.

Create user with activate

POST /api/v1/users creates a user in STAGED state by default. Adding the activate=true query parameter activates the user immediately after creation.

Group rules

Expression-based rules assign users to groups automatically. Rules run asynchronously, so membership changes may lag minutes behind profile updates.

Profile mastering

Determines the source of truth for user attributes. When an external source masters the profile, Okta edits may be overwritten on the next import.

Deactivate vs delete

Deactivating sets the user to DEPROVISIONED and blocks sign-in while retaining the record. Deleting removes the user but requires prior deactivation.

Change password endpoint

POST /api/v1/users/{id}/credentials/change_password updates a password. Self-service changes require the old password in the request body.

SCIM deprovisioning

Okta sends a PATCH setting active=false or a DELETE to the app. The app user is deactivated, but the Okta user record persists unless separately deactivated.

Profile mapping direction

Okta to App mappings push attributes during provisioning. App to Okta mappings import attributes during sign-in or scheduled import runs.

Suspend user endpoint

POST /api/v1/users/{id}/lifecycle/suspend moves an ACTIVE user to SUSPENDED, blocking sign-in. Unsuspend returns the user to ACTIVE without re-enrollment.

Unlock user endpoint

POST /api/v1/users/{id}/lifecycle/unlock clears a LOCKED_OUT state caused by failed logins, allowing the user to authenticate again without a password reset.

Reset password endpoint

POST /api/v1/users/{id}/lifecycle/reset_password generates a recovery flow. The sendEmail parameter controls whether Okta emails the reset link to the user.