The following reconfiguration has been identified as part of the preparation needed to perform the upgrade to Okta Identity Engine (OIE). Note, additional Okta features may require reconfiguration or be disabled in order to complete the upgrade..

Custom Sign-in/Login using AuthN API with OIDC/OAuth Authorization param sessionToken
Complexity Level: INFO/ WARNING

How does this blocker impact the upgrade to OIE?
This is a method to challenge authentication via back-end service (aka Server-side auth, Proxy, API gateway, or custom Login application) using the okta /authn/ API 

Once the authentication challenge is complete, the Okta authn API returns a sessionToken and the service directs the Browser/Client to a URL such as “/oauth2/v1/authorize?client_id=...sessionToken=[SessionToken]”

This will establish an “okta Global Session” in the client… This is to support SSO between multiple applications.  

Especially in Legacy Applications with custom Sign-in Flow as they require an assertion in HTTP header.

Currently, it will work in a classic manner in OIE (Global Sign-on Policy); however, it will NOT support the OIE application sign-on policies, There are no plans to support the same redirection method in OIE.

Risk

• New Authentication Policies and experiences will not be enforced.

• Global Policy will require more restrictions than application.

(sessionToken is generated via okta /authn/ API, just no app content)

Recommendations

• Leave Classic Global Sign-in Policy in place while custom sign-in is refactored.
• OR Replace the sign-in flow with applicable redirection integration deployment model.
• OR Replace the sign-in flow with SDK.

Is there additional training or information I can use to help me with this remediation?
Yes, visit Scope values for additional legacy integration reference information.