Validator: PASSWORD_BASED_AUTH_SESSION
Upgrade Eligibility: Eligible - Consent Required
This org is creating sessions via the "Sessions API" with username and password [/api/v1/sessions]. After upgrading to Okta Identity Engine, this method will no longer function breaking ANY custom authentication flow where this API used. This WILL break all 3rd party integrations that use this method, such as Snowflake or AWS RedShift if not updated properly.
URGENT Snowflake Customers: There are known issues with older versions of the Snowflake database connector and Okta Identity Engine; upgrading without having the correct driver installed will cause Snowflake to stop functioning upon upgrade. Please refer to the article below to ensure you have installed a compatible version prior to upgrade to avoid any impact to Snowflake: https://support.okta.com/help/s/article/Snowflake-ODBC-Connector-Compatibilitywhen-Upgrading-from-Okta-Classic-Engine-to-Okta-Identity-Engine
URGENT Amazon Redshift Customers: There are known issues with older versions of the Amazon Redshift using JDBC or ODBC database connectors and Okta Identity Engine; upgrading without having the correct driver installed will cause Amazon Redshift to stop functioning upon upgrade. Please refer to the article below to ensure you have installed a compatible version prior (Amazon Redshift ODBC driver 1.3.6.1000 or later) to upgrade to avoid any impact: https://docs.aws.amazon.com/redshift/latest/mgmt/generating-iam-credentials-configure-jdbc-odbc.html
How does this blocker impact the upgrade to OIE?
This will not prevent the upgrade from executing, however will have impact to the Integration that is using this sign-in method if not addressed.
The usage that was detected from the sessions API format:
POST: {{org}}/api/v1/sessions?additionalField=cookieTokenOr
POST: {{org}}/api/v1/sessions?additionalField=cookieUrlBoth are Deprecated properties of the sessions API.
User account credentials would be posted to the API and it would return a “cookieToken” or Url to a 1x1 pixel image. cookieToken, Another one-time token that is used to obtain a session cookie by visiting either an application's embed link or a Session redirect URL.
For example adding to the SAML IdP initiated URL:
GET: {{org}}/app/././sso/saml?onetimetoken={{cookieToken}}cookieTokenUrl, The URL for a transparent 1x1 pixel image that contains a one-time session token that, when visited, sets the session cookie in your browser for your organization.
How do I remediate this blocker?
This feature will not prevent the Okta Identity Engine upgrade; however there is significant impact to the way Okta Identity Cloud can authenticate with the appropriate level of assurance post-upgrade and may impact to the user experience or the general functionality. Contact your Okta Administrator to understand the potential impact listed below.
To identify how this is implemented, perform the System log query:
debugContext.debugData.requestUri eq "/api/v1/sessions" and (eventType eq "user.session.start" or eventType eq "user.authentication.auth") and not (client.userAgent.rawUserAgent co "OktaMobile") and not (client.userAgent.rawUserAgent eq "com.okta.ios.mobile")
Reconfiguration Impact
Ideally if this is a user authentication flow, moving to a modern “redirection” or implementing a SDK flow would be the best approach; Start on our “sign users in overview” to choose the right solution four your application.
Ref: https://developer.okta.com/docs/guides/sign-in-overview/main/
If there is a requirement to maintain this authentication flow in back-end API, use the Authentication API that supports the full user authentication pipeline and produces a sessionToken that you can use in this API.
Ref: https://developer.okta.com/docs/reference/api/authn/#primary-authentication
Post-Upgrade Impact
If remediation is not completed prior to the authentication flows will stop working and need to be updated;
