Okta Certified Professional flashcards
Okta Certified Professional · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- STAGED user status
- A user created by import or admin action who has no credentials and cannot sign in until activated. Staged users may be assigned apps but cannot authenticate.
- PROVISIONED user status
- A user who has been assigned an app but has not yet completed activation. The user has an Okta profile but no active sign-in capability until activation finishes.
- DEPROVISIONED user status
- A user whose profile has been removed from active use. The user cannot sign in, group memberships and app assignments are cleared, and reactivation is required to restore access.
- SUSPENDED user status
- A temporary block on sign-in that preserves the user's profile, group memberships, and app assignments. Reactivating a suspended user restores access without re-provisioning.
- Okta group types
- Groups are either OKTA_GROUP, created and managed inside Okta, or APP_GROUP, imported from an application through profile sourcing or group push. Membership rules differ by type.
- Group rules
- Automated rules that assign users to a group when profile attributes match conditions. Rules run on user creation and profile update, and can also remove users when conditions no longer match.
- Profile mastering
- The setting that decides which source owns a profile attribute when multiple sources provide a value. The mastering source wins on conflict; non-mastering sources are read-only.
- Profile sourcing
- Importing user attributes from an application into Okta's Universal Directory. It makes the app a possible master for those attributes and requires an import-capable app integration.
- Group push
- Sending Okta groups and their memberships to a connected application. It requires provisioning enabled on the app and is used to keep app-side groups aligned with Okta.
- CSV user import
- A bulk upload that creates or updates users from a file. Rows are validated individually, errors are reported per row, and successful rows are committed without rolling back the file.
- Password policy scope
- Password policies are assigned to groups and evaluated by priority; the first matching policy applies. Settings include length, complexity, history, lockout, and idle timeout.
- Admin role scoping
- Admin roles grant permissions over specific resources. Super Admin is unrestricted; Group Admin and Help Desk Admin are limited to assigned groups and permitted actions such as password reset.
- SAML assertion validation
- The service provider checks the assertion signature against the IdP certificate, then validates Audience, Recipient, and time conditions. Expired certificates and clock skew cause most failures.
- NameID format
- The SAML setting that defines how the user identifier is expressed in the assertion, such as unspecified, emailAddress, or persistent. It must match what the service provider expects.
- SAML attribute statements
- Mappings that send Okta profile attributes into the SAML assertion so the service provider can read them. Each statement has a name, a value expression, and an optional namespace.
- SP-initiated SAML flow
- The user starts at the application, which redirects to Okta for authentication. Okta then posts a signed assertion back to the app's ACS URL; ACS URL and Audience must match.
- IdP-initiated SAML flow
- The user starts at the Okta dashboard and selects the app. Okta sends an unsolicited signed assertion to the app's ACS URL without a preceding app-side request.
- OIDC ID token
- A signed JWT issued by Okta as OpenID Provider. The app must validate issuer, audience, expiry, and nonce, and verify the signature using keys from the org's JWKS endpoint.
- SWA app mode
- Secure Web Password SSO, where Okta stores app credentials and replays the login form for apps without federation. Some flows require the Okta Browser Plugin.
- Bookmark app
- An app configured with no SSO integration that appears on the Okta dashboard as a link. It provides no federation or credential replay and only launches the target URL.
- App sign-on policy
- A per-application policy whose rules are evaluated by priority. The first matching rule sets authentication requirements such as MFA, session lifetime, and access denial.
- Global session policy
- An org-wide policy that controls session lifetime and idle timeout and can require MFA for all users. It is evaluated before app-level authentication rules.
- WS-Federation
- A federation protocol supported by Okta with a trust model similar to SAML but a different message format. It is commonly used for Microsoft-centric applications.
- ACS URL
- The Assertion Consumer Service endpoint on the service provider where Okta posts the SAML assertion. A mismatch between Okta and the app configuration breaks SP-initiated sign-in.
- Network zone
- A named set of IP ranges or geolocations used as a policy condition. Zones can be blocklisted or allowlisted and are referenced by sign-on and MFA policies.
- Okta Verify factor
- An MFA authenticator that supports push notifications, TOTP codes, and FastPass. Enrollment and enforcement are controlled by the authenticators page and MFA policies.
- WebAuthn authenticator
- A phishing-resistant MFA factor using public-key credentials bound to the origin. It can be used with hardware keys or platform biometrics and is configured on the Authenticators page.
- Lockout policy settings
- Password policy values that define the number of failed attempts before lockout and how long the lockout lasts. They apply to the users assigned to that policy.
- API token scope
- An Okta API token inherits the permissions of the admin who created it and is displayed only once. Tokens should be rotated and replaced with scoped OAuth service apps where possible.
- System Log fields
- Each entry records event type, actor, target, outcome, and timestamp. Logs can be searched, exported, and streamed to a SIEM for retention and alerting.
- ThreatInsight
- A risk signal that flags sign-in attempts from suspicious IPs or behavior observed across Okta's network. Policies can require step-up authentication when risk is detected.
- Admin console MFA
- An org security setting that requires a second factor for administrators signing in to the Okta admin console, separate from end-user application MFA policies.