Okta Certified Administrator · Part I

Identity and Access Management

36% of the exam — the single largest domain.

Identity & Access Management

Module 2: Single Sign-On (SSO) Federation

4 sub-topics · this deck covers sub-topic 3 of 4

The Exam Bullet

"Demonstrate knowledge of the configuration of OIN apps"

The Okta Integration Network (OIN) is the catalog of app connections Okta already knows how to talk to. This sub-topic covers what's actually configurable once one of those apps is added — not just clicking "assign."

The Mechanism

An OIN app integration is a configured connection between an Okta feature and an external app — either a prebuilt catalog entry or a custom connection using SAML, OIDC, or Secure Web Authentication. Account provisioning between the two can be handled through SCIM.

Once configured, admins can assign the integration to groups or individuals, enable SSO, and keep account data synchronized both ways.

The Gotcha — CASB Override

A Cloud Access Security Broker (CASB) sits between the org and its cloud apps to enforce security policy. Okta lets you override four SAML properties on OIN/Office 365 apps to make that integration work, all inside the $app.settings.signOn object:

ssoAcsUrlOverride — Assertion Consumer Service URL
audienceOverride — Audience
destinationOverride — Destination
recipientOverride — Recipient

These are set via the Okta API (fetch app settings, edit the signOn section, then PUT the update). For Office 365 specifically, WS-Federation must be set to Manual configuration to avoid errors with multiple domain federation.

The Gotcha — Password Reveal

Admins must explicitly enable Password Reveal per app — it's off by default, and it's unavailable for apps using admin-set or shared credentials.

Revealed password auto-hides after 1 minute · reauthentication required if 15+ minutes since login · transmission uses SSL

Credentials are stored encrypted with a tenant-specific private key. The feature exists specifically for cases like re-entering a long generated password on another device — but only for individually-assigned credentials, never shared ones.

The Gotcha — Self-Service Approval Workflow

This lets app owners (not just IT) manage access requests. Requires Super or app admin rights, plus Self-Service enabled org-wide.

Configuration: turn on "Allow user to request app," optionally require approval, assign approvers (max 100 per group) with Hidden/Read/Write rights, chain up to 10 approval levels without repeating an approver, and set a response window (1 week, 30 days, or custom).

Key limitation: this workflow can't be used with apps that require personal attributes. Best practice: make sure at least one approver can edit attributes if the app needs provisioning setup.

The Exam Angle

Watch for scenario questions built around these traps:

→ "A CASB proxy needs a different Assertion Consumer Service URL than the default OIN app uses." = ssoAcsUrlOverride via the API.

→ "A user can't reveal their password for a shared-credential app." = expected — Password Reveal doesn't work for shared credentials.

→ "An app with required personal attributes needs a self-service request flow." = not supported — explicit limitation.

One Line To Remember

OIN apps = prebuilt or custom (SAML/OIDC/SWA) connections, SCIM for provisioning. CASB override = 4 signOn properties via API (ACS URL, audience, destination, recipient). Password Reveal = admin-enabled, 1-min auto-hide, 15-min reauth, never for shared creds. Self-Service Approval = up to 10 levels, 100 approvers/group, can't combine with apps needing personal attributes.

Sources: help.okta.com — Apps_Apps.htm · CASB-config-guide.htm · Apps_Revealing_the_Password.htm · apps-selfservice-configureapprovalflow.htm

Next: Sub 4 →