Okta Certified Developer key terms

The top-level tenant that holds all users, groups, applications, policies, and authorization servers for a customer. Every API call targets a specific org through its base URL.

The unique hostname assigned to an org, such as example.okta.com, used as the base for all API endpoints, OIDC issuer values, and SAML metadata URLs. Custom domains can replace the default.

A long-lived secret string sent in the Authorization SSWS header to authenticate administrative REST calls. It inherits the permissions of the admin who created it and is not scoped per endpoint.

The authentication scheme prefix used with Okta API tokens, written as Authorization: SSWS {token}. It tells the org to validate the request as an administrative call rather than a user-context OAuth bearer token.

An app integration with client credentials grant used for machine-to-machine API access. It carries scoped Okta management grants, replacing legacy API tokens with least-privilege authorization.

A per-org cap on API requests in a time window, enforced per endpoint category. Exceeding it returns HTTP 429 with an X-Rate-Limit-Reset header, so clients should back off and retry.

The pattern of retrieving large result sets in pages using a cursor link in the HTTP Link response header with rel="next". Developers must follow that link rather than constructing offsets manually.

The REST resource family under /api/v1/users for creating, reading, updating, deactivating, and deleting user profiles. It supports filtering, search, and lifecycle operations through dedicated sub-endpoints.

The set of attributes stored for a user, governed by a profile schema that defines which fields exist, whether they are required, and who may read or write them.

The JSON definition of a user type's attributes, including data type, required flag, and permission level. Custom attributes added here become available in mappings and app assignments.

The state of a user account, such as ACTIVE, STAGED, PROVISIONED, SUSPENDED, DEPROVISIONED, or LOCKED. Transitions are triggered by lifecycle endpoints and drive downstream app provisioning.

Dedicated endpoints that move a user between states, for example /lifecycle/activate, /lifecycle/deactivate, /lifecycle/suspend, and /lifecycle/reset_password. They trigger policy and provisioning side effects.

Okta's cloud store for user profiles, groups, and device data. It unifies identity data from multiple sources and applies mappings so applications receive consistent attributes.

A configuration that translates attributes from a source profile, such as an identity provider or directory, into an application's target profile. Mappings control what values downstream apps receive.

A named collection of users used for access control, app assignment, policy targeting, and group-based licensing. Groups can be created locally or imported from directories and are addressed by a stable ID.

An expression evaluated by Okta to automatically add or remove users from a group based on profile attributes. Rules reduce manual administration and are commonly used to drive app assignment.

Okta's syntax for writing conditions and value transformations in group rules, policy rules, and attribute mappings. It supports functions, string operations, and references to user profile fields.

The link granting a user or group access to an application integration. Assignment determines who sees the app in the dashboard and whether provisioning or SSO is triggered.

A federated authentication flow where a user authenticates once at an identity provider and is granted access to multiple applications without re-entering credentials at each one.

An XML-based federation standard where an identity provider issues signed assertions about a user to a service provider. Okta can act as either party, exchanging metadata to establish trust.

The signed XML document containing authentication statements and attribute statements about a user. The service provider validates the signature and consumes the attributes to create a session.

The system that authenticates a user and asserts identity to other parties. In SAML and OIDC flows, Okta commonly serves this role, but external IdPs can also be configured as inbound sources.

The application that relies on an identity provider's assertion to authenticate a user. It trusts the IdP's signing certificate and consumes the assertion or token to establish a local session.

An identity layer on top of OAuth 2.0 that adds an ID token and a UserInfo endpoint. It is the standard protocol for Okta-hosted and embedded sign-in in modern applications.

A framework for delegated authorization that issues access tokens to clients so they can call protected resources on a user's behalf without handling the user's password.

The OAuth grant where the client receives a short-lived code via browser redirect, then exchanges it server-side for tokens. It is the recommended flow for server-rendered web applications.

Proof Key for Code Exchange, an extension that binds the authorization request to the token request using a code verifier and challenge. It protects public clients such as mobile and single-page apps.

A signed JWT returned by OpenID Connect that contains claims about the authentication event and the user, such as subject, issuer, audience, and expiry. Clients validate it before trusting identity.

A credential presented to a resource server to authorize API calls. It carries scopes and claims, has an expiry, and should be validated for signature, issuer, audience, and lifetime.

A long-lived credential used to obtain new access tokens without user interaction. Rotation and reuse detection limit the damage if a refresh token is stolen.

The practice of issuing a new refresh token each time one is redeemed and invalidating the previous one. Reuse of an old token signals theft and can revoke the whole token family.

Name-value pairs inside a token or assertion describing the subject, issuer, audience, scopes, and custom attributes. Applications read claims to make authorization decisions.

Space-delimited strings that request specific permissions or data access in an OAuth request. The authorization server must grant them before the corresponding claims or API capabilities are returned.

The Okta component that issues OAuth tokens and enforces scopes, claims, and access policies. Orgs have a built-in org server plus any custom authorization servers developers create.

The public identifier assigned to an app integration. It is sent in authorization requests and token calls to tell the authorization server which client is making the request.

A confidential value paired with a client ID to authenticate the app at the token endpoint. It must never be exposed in browser or mobile code and is omitted for public clients.

A client authentication method where the app signs a short-lived assertion with its private key instead of sending a shared secret. It is the strongest option for confidential server clients.

The callback address registered on a client where the authorization server sends the user with a code or token. It must match exactly, otherwise the request is rejected to prevent token leakage.

Requiring a second proof of identity, such as a push approval, TOTP code, or security key, beyond the password. Okta enforces it through authenticator enrollment and policy rules.

A factor enrolled by a user, such as Okta Verify, WebAuthn, SMS, or a password. Authenticators are registered per user and evaluated by authentication policies during sign-in.

A set of rules evaluated by an authorization server that decides whether a client may receive tokens, which scopes are allowed, and what assurance the user must satisfy.

Challenging a user for stronger proof at the moment a sensitive operation is attempted, rather than at initial sign-in. It is often triggered by an acr_values request or a policy condition.

Routing a user to the correct identity provider before authentication, typically by email domain or an org-level policy. It is essential when an org federates with multiple external IdPs.

The XML or JSON document exchanged between SAML or OIDC parties that lists endpoints, entity IDs, and signing certificates. Importing it establishes federation trust without manual entry.

Automatically creating, updating, and deactivating user accounts in downstream applications based on Okta assignments and profile changes. It keeps app accounts aligned with the directory.

System for Cross-domain Identity Management, a REST standard for exchanging user and group resources between Okta and apps. It defines schemas and endpoints for automated provisioning.

A webhook that Okta calls when specified events occur, such as user creation or deactivation. It delivers a signed request to an HTTPS endpoint so external systems can react in near real time.

A synchronous callback that pauses an Okta flow, sends context to an external HTTPS service, and uses the response to continue. Common uses include token enrichment and import validation.

The audit record of authentication, admin, and lifecycle events in an org. It is queryable through the API and is the primary source for troubleshooting and compliance reporting.

A JavaScript library that renders Okta's hosted authentication experience inside an application. It supports embedded flows, factor enrollment, and policy-driven challenges without custom UI work.

Handling sign-in inside the application's own UI by calling Okta authentication APIs or the Sign-In Widget, rather than redirecting users to a hosted Okta page.

The process by which a user registers authenticators so they can satisfy multifactor requirements. Enrollment can be required by policy before access is granted.