Okta Certified Consultant key terms

The top-level Okta tenant that holds all users, groups, apps, policies, and branding for a single customer environment. Each org has its own unique subdomain and is administered separately.

An isolated Okta infrastructure unit hosting many orgs in a region. Cells provide fault isolation and data residency; an org lives in exactly one cell, which affects failover and latency.

The web interface where administrators configure users, apps, policies, and settings. It exposes most platform capabilities without API calls and is the primary tool for daily administration.

Okta's cloud user store that holds profiles from Okta and connected sources. It lets you define custom attributes, apply mappings, and treat multiple identity stores as one directory.

Configuration that copies attribute values from a source profile into a target profile, such as from an identity provider to the Okta user profile. Mappings can be expression-based and are evaluated at runtime.

The individual field-level rule inside a profile mapping that assigns a target attribute a value from a source attribute, constant, or expression. Wrong mappings are a common cause of missing or overwritten user data.

A small expression syntax used in mappings, policies, and app settings to transform values, reference user attributes, and apply functions such as string manipulation or conditional logic. It is evaluated server-side by Okta.

The authoritative system for a user's attributes, such as Okta itself, an Active Directory domain, or an external IdP. Choosing the source determines which system wins when attributes conflict.

The rule set deciding which connected source is authoritative for each user attribute when several sources provide values. It prevents conflicting writes and defines precedence across directories and IdPs.

A lightweight on-premises service that connects Okta to Active Directory for user import, authentication, and password sync without opening inbound firewall ports. It runs on a domain-joined Windows server.

An Okta-provided LDAP endpoint that lets legacy applications authenticate users against Universal Directory without an on-premises directory. It supports bind and search operations over TLS.

Configuration where Okta acts as the service provider and trusts an external identity provider to authenticate users. It is used for partner access, acquisitions, or IdP consolidation.

Configuration where Okta acts as the identity provider and sends assertions to another application or IdP. It centralizes authentication and enables single sign-on to external relying parties.

An XML-based federation standard where an identity provider issues signed assertions to a service provider. Okta supports both SP-initiated and IdP-initiated flows and requires matching certificate and ACS settings.

An identity layer on OAuth 2.0 where the IdP returns a signed ID token with user claims. It is the preferred modern protocol for web and mobile apps integrated with Okta.

The signed statement a SAML IdP sends to a service provider describing the authenticated user and attributes. Signature, audience, and timing must validate or the login fails.

The Assertion Consumer Service endpoint on a service provider where the IdP posts SAML assertions. A mismatch between Okta and the app configuration is a frequent cause of failed sign-on.

A signed JWT returned by an OIDC provider containing claims about the authenticated user, such as subject, issuer, and expiry. Applications validate it to establish the user's identity.

A credential issued by an authorization server that grants a client access to protected resources. In OIDC flows it is separate from the ID token and carries scopes rather than identity claims.

An authorization framework that issues access tokens to clients for protected APIs. Okta uses it for API access management and as the foundation for OIDC sign-in flows.

A named permission requested by an OAuth client that limits what an access token can do. Scopes are defined on an authorization server and enforced by the resource server.

The Okta component that issues OAuth 2.0 and OIDC tokens. The org authorization server serves Okta APIs, while custom authorization servers define their own scopes, claims, and access policies.

Creating or updating a user in an app at first sign-on rather than in advance. It reduces pre-provisioning effort but can leave orphaned accounts if the app is not also deprovisioned.

A standard REST protocol for exchanging user and group data between Okta and applications. It powers automated provisioning and deprovisioning for apps that support it.

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

Removing or disabling an app account when a user loses access, typically triggered by unassignment or deactivation in Okta. It is a core control for reducing orphaned accounts.

The end-to-end handling of a user's access from onboarding through role changes to offboarding. In Okta it combines directory state, assignments, provisioning, and deactivation rules.

An expression-based rule that automatically adds or removes users from a group based on profile attributes. It keeps group membership current for app assignments and policies.

A collection of users used to bundle app assignments and policy targeting. Groups can be created manually, synced from directories, or populated dynamically by rules.

The link granting a user or group access to an application. Assignment controls who sees the app in the dashboard and often triggers provisioning or policy evaluation.

Okta's layered system of global and app-level policies that evaluate sign-on, authentication, and access conditions. Policies are ordered, and the first matching rule determines behavior.

A policy that defines which authenticators and factors a user must satisfy to sign in to an org or app. Rules can branch on network zone, device, group, or risk signals.

A single condition-and-action entry within a policy, evaluated in priority order. The first matching rule applies, so ordering and catch-all rules are critical design decisions.

A named set of IP ranges and geolocations used in policy conditions to distinguish trusted, corporate, or blocked traffic. Zones can be dynamic or static and are referenced by policy rules.

Requiring two or more independent factors during sign-in, such as a password plus Okta Verify push. Okta enforces MFA through authenticator enrollment and authentication policies.

A method or device a user registers to prove identity, such as a password, TOTP app, security key, or Okta Verify. Authenticators are enrolled per user and constrained by policy.

A phishing-resistant passwordless sign-in using Okta Verify with biometric or device PIN verification. It binds authentication to the device and reduces reliance on shared secrets.

A secret credential used to authenticate calls to the Okta Management API, scoped to the admin who created it. Tokens are long-lived and should be rotated and stored securely.

A cap on how many API requests Okta accepts in a time window per endpoint and org. Exceeding it returns HTTP 429, so integrations must back off and retry gracefully.

Okta's audit record of authentication, admin, and provisioning events, queryable in the console or via API. It is the primary evidence source for troubleshooting and compliance reporting.

The requirement that identity data stays within a specified geography. Okta addresses it by placing orgs in regional cells, which affects where data is stored and processed.