> For the complete documentation index, see [llms.txt](https://docs.1kosmos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.1kosmos.com/authentication/passwordless-for-web-apps/login-methods/password-reset.md). # Password Reset *** ### Overview The configuration lives under **Authentication > Reset Password** in AdminX, where you can enable one or more reset methods depending on your organization's security requirements. ### Methods to Reset a Password * **Reset via AdminX** — sends a reset link by email, or a link combined with a passcode to the user's registered phone * **Reset via Mobile App** — allows users to reset directly from the 1Kosmos mobile app; must be explicitly enabled even if mobile resets were previously working * **Reset via Identity Verification** — users verify their identity using a government-issued document before resetting. You also choose the identifier users enter on the Forgot Password screen — either their **email address** or **username**. If username is selected, the reset link is sent to the email address associated with that account. Once configured, click **Save**. ### Resetting via AdminX When AdminX-based reset is enabled, users click **Forgot Password?** on the login screen and enter their email or username. From there, the flow depends on the method configured: * **Email link only** — user receives a reset link, clicks it, and sets a new password * **Email link + passcode** — user receives the link and also a passcode on their registered phone; both must be used to complete the reset {% hint style="info" %} The reset link is valid for **30 minutes**. If a user has multiple accounts tied to the same email address, they'll be prompted to select which account to reset. {% endhint %} **Event Logs** — `E_PWDRESET_SUCCEEDED` and `E_PWDRESET_FAILED` are triggered on completion or failure. ### Identity Verification-Based Reset (SSPR) The self-service password reset (SSPR) feature lets users verify their identity using a valid identity document before resetting their password, no admin intervention needed. To enable it, turn on **Enable users to reset password through Identity Verification** under **Authentication > Reset Password > Reset Password Configurations**. #### How It Works The user clicks **Forgot Password**, enters their email, selects how they want to receive the verification link, and completes a document scan + selfie. Once identity is verified, they're taken directly to the password reset screen. {% hint style="warning" %} The password must be reset within **3 minutes** of identity verification. After that, the token expires and the process must be restarted. {% endhint %} #### Name Alias Matching Community Administrators can configure name aliases to handle common name variations during document matching, for example, mapping "Joe" to "Joseph" or "Mike" to "Michael". These are defined as a dictionary in the SSPR settings. #### Workday Integration If your organization uses Workday as the user attribute source, configure the following before enabling SSPR: * An Active Directory (AD) to 1Kosmos connection is required * Map Workday attributes to one of: `$employeeId`, `$username`, or `$email` * Write a transformation script to convert the Workday API response into 1Kosmos session attributes (first name, last name, DOB) * Enable the Workday option in SSPR settings; otherwise the system defaults to your preferred user store (e.g. AD) The Workday configuration screen accepts the API URL, authorization type (Basic Auth, Bearer Token, or No Auth), and a script editor where you can write and test your transformation logic before saving. {% hint style="info" %} Saving Workday configuration changes requires identity verification — you'll be prompted for a one-time code via email or SMS before changes are applied. {% endhint %} #### SSPR Event Logs The `E_IDV_DOCUMENT_VALIDATE` event is enhanced with fuzzy match scores and a session summary certificate. Both `E_PWDRESET_SUCCEEDED` and `E_PWDRESET_FAILED` include a `mode` field indicating how the reset was attempted: `email_link`, `email_link_with_otp`, `id_proofing`, `Authenticator`, or `Other`. For `id_proofing` mode, the session ID is also included. Common failure scenarios and their error messages: | Scenario | Error Message | | ------------------------------- | ------------------------------------------------------------- | | Generic password change failure | Generic error: Error while changing user password | | Password login not allowed | Your organization does not allow you to login with a password | | ID proofing not configured | DVCID not configured in SSPR settings | | ID proofing session expired | ID Proofing session is expired | | Document verification failed | Document verification failed | | User disabled or inactive | User is disabled / User is inactive | | Missing required attribute | employeeId / username / email is missing in the user object | | Transformation script failure | Transformation script failed | *** ### Enforcing Password History 1Kosmos supports password history enforcement during resets across all methods, mobile, AdminX, and identity verification. When enabled, users cannot reuse recently used passwords. Enable it via **Authentication > Reset Password > Password Reset Settings > Enforce Password History Check** in AdminX. {% hint style="info" %} **Prerequisites:** Go Broker service v1.09.02 or later, and password history must also be configured at the Active Directory level via Group Policy. {% endhint %} #### Configuring Password History in Active Directory In Group Policy Management, navigate to: **Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy** Set **Enforce password history** to the number of previous passwords to remember, and ensure **Minimum password age** is greater than 0. Run `gpupdate /force` to apply. When a user tries to reuse a previous password during reset, they'll see: --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.1kosmos.com/authentication/passwordless-for-web-apps/login-methods/password-reset.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.