This article explains the expected behavior of the password reset flow when Universal Login (UL) is configured with an identifier-first authentication profile. An administrator observes two main behaviors:

• A user enters an identifier on the login screen, selects the Forgot Password? link, and then enters a different identifier on the password reset screen. The password for the account associated with the second identifier is reset, while the password for the account associated with the first identifier remains unchanged.

• The password reset form pre-populates with the identifier from the initial login screen. This occurs even if the user's connection does not support password resets with that type of identifier, which may prevent the user from completing the flow.

• Universal Login
• Identifier-First Authentication Flow

This behavior occurs by design in the identifier-first authentication flow.

When a user selects the Forgot Password? link, the system initiates a new and separate process that is independent of any information entered on the previous login screen. The system discards the original identifier and prompts for a new one to use for the password reset action. The password reset ticket is then generated for the new identifier provided on the Forgot Password screen.

The user interface pre-fills the identifier from the login screen into the password reset form. This can cause an issue if the user's connection is not configured to allow password resets with that specific type of identifier (for example, pre-filling a username when only a phone number is permitted for resets).

This is the expected functionality for the identifier-first flow.

To confirm that the password for the originally intended account was not changed, attempt to sign in to that account using its original password. Access is granted if the password reset flow affected a different account.

NOTE: A direct workaround is not currently available for the issue where an unsupported identifier is pre-populated in the password reset form. This is a known limitation, and a future feature enhancement is planned to address this behavior.