Transition Plan for the New Okta User and Agent Access Control Model

Okta changes the Application and Agent relationship model in O4AA to a new User Access model that introduces a shared Open Authorization (OAuth) client bound to both the Application and the Agent. Existing integrations using the deprecated User Sign-On Application pattern for User On-Behalf-Of (OBO) flows require migration to the new client binding model. Migrate existing integrations by recreating relationships and updating credentials.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• O4AA
• Open Authorization (OAuth) Client Binding
• Agent-to-Agent (A2A) flows
• User On-Behalf-Of (OBO) flows

What is the scope of impact for the new user and agent access control model?

• Integrations with multiple User Sign-On Applications or multiple Agents require reconfiguration to a one-to-one binding between the Application and the primary Agent. The Agent-to-Agent (A2A) pattern manages additional Agent invocations.
• The earlier model for User On-Behalf-Of (OBO) authentication flows is deprecated and requires replacement.
• Current integrations using the deprecated model continue to function but become uneditable.

The new user and agent access control model requires specific migration actions.

Migrate existing integrations using the deprecated model to the new client binding model by recreating relationships and updating credentials.

1. Review the User and Agent Access model for new integrations.
2. Recreate the Agent and Application relationships using the client binding model.
3. Update the OAuth client credentials in all relevant configurations and vaults outside of Okta to reflect the new, shared bound OAuth client credentials.
4. Define a single one-to-one mapping of the Application to the Agent for integrations where multiple agents associate with the same User Sign-On application via the deprecated model.
5. Model all subsequent Agent interactions within the application via A2A patterns