Okta API Set Password with hashed password

Is there a way i can hash the password when using Okta API to set password?

Currently it only accepts plain-text password value

if i try to add the hash in the API body i get the below:
“errorSummary”: “password: An imported password may only be specified for a user with status: STAGED”

I know i can import a user with a hashed password as per documentation below.

The error explains it clearly. To use a hashed password they need to be a certain status otherwise it needs to be plain text

Hi abroadhurst,

I understand the error, what i am asking is why i cannot used a hashed password when using Set-Password.

Double-check to ensure your parameters abide by the Password Object logic.

The info below should help.

Hashed Password Object

Specifies a hashed password to import into Okta. This allows an existing password to be imported into Okta directly from some other store. Okta supports the BCRYPT, SHA-512, SHA-256, SHA-1, and MD5 hashing functions for password import. A hashed password may be specified in a Password Object when creating or updating a user, but not for other operations. See Create User with Imported Hashed Password for information on using this object when creating a user. When updating a user with a hashed password the user must be in the STAGED status.

Hi @jamesm

At the moment, Okta does not support set password operation with hashed password.

Hi Dragos,

Thank you for this response. This is what i thought but wanted to make sure.

Do you know if this is on the roadmap in the near future?

Hi @jamesm

At the moment no. I have moved this topic in the Feature Requests section in order to increase it’s visibility to the engineering team and have it possibly implemented in the near future.

The ability to update a user’s credentials with a hashed password would be helpful for me.

We are about to migrate 250,000 customers into Okta. With a rate limit of 300 requests/minute this would take a minimum of 14 hours (but may take much more if we have to do multiple API calls per user).

A nice approach would be to “premigrate” all of the customers in advance, and then at go-live just update any that have changed since the premigration. (Our legacy authentication system records the last-updated timestamp.) However, this is not possible if we cannot update the hashed password, because some customers might change their passwords between premigration and go-live.

Currently we’re looking at a many-hour outage for our customers, because we’ll have to be offline for the entire migration.

Would love to hear alternative suggestions.

Hi @johnhurst

You can use the Password Import Inline Hook functionality which provides a bridge between Okta and another application for password import. The process would go as follows:

  • user is created in Okta using a request like the one available here
  • when the user authenticates the first time, Okta sends the username and password to a webhook on your end
  • your webhook captures the credentials, does a legacy authentication and, if credentials are correct, it returns "credential":"VERIFIED"
  • if Okta sees VERIFIED, it will hash the password and save it locally, without sending any further requests to the webhook for the specific user


Thanks for your suggestion. As I understand it this would be a form of Hybrid Live Migration as described in the “Okta User Migration Guide” data sheet. This would require changes to our application during the transition. (The new web hook.)

One advantage of the “premigration” approach, which aligns with “Bulk Import” in the Migration Guide, is that no changes are required in the application prior to go-live. There is the legacy application, the new Okta-based application, and no in-between.

We have thought of another alternative for premigration. The premigration records the users, bcrypted passwords and timestamps it migrates. Then when synchronizing, it can check if a password has changed. For a changed password, because Okta does not yet support Update of hashed password, it can Delete the user in Okta and re-Create it.

Sounds a bit convoluted, but this allows premigration to occur over an arbitrary period of time without any changes yet to the existing legacy application.

Hi @johnhurst

Please note that, when deleting the user and recreating it, there might be issues occurring with user synchronization in other apps in Okta, such as Office 365 or G Suite as a recreated user has a different user ID and it would need to be re-added to the application.