For customers hooking into the SIW (Sign In Widget) elements for monitoring or testing purposes, this article explains the changes in elements between Classic and Okta Identity Engine (OIE) and even between Sign in Widget versions, and how to manage them.

• Sign In Widget Elements

When upgrading from Classic Engine to Okta Identity Engine (OIE), certain values in the DOM structure will change, causing monitoring or testing tools that hook into these values to fail.

Example:

• Classic Values example:

  type("//input[@id='okta-signin-username']", "${username}")
  type("//input[@id='okta-signin-password']", "${password}")
  clickAndWait("//input[@id='okta-signin-submit']")

• OIE Values example:

  type("//input[@id='input28']", "${username}")
  type("//input[@id='input36']", "${password}")// Step - 3
  clickAndWait("//input[@value='Sign in']")

In the DOM structure, id and class values can change across generations and even between major, minor, and patch versions of the Sign In Widget.

If hooking into the Sign In Widget elements for customization or testing, it would be advised to use the data-se attributes. These are less likely to change, as these are also used for Okta's internal automation testing.

• A JS example for the username:

  document.querySelectorAll('[data-se="o-form-input-identifier"] > input[name="identifier"]')

Okta does not provide information on when these values will change.

The recommendation is to utilize the preview environment to execute tests and also hook the monitoring tools into the preview environment.

Any changes made to the Sign In Widget will be first deployed to the preview environment and then to the production environment (usually around a week before). This way, any changes will be alerted before they go into production.