Okta API Set Password with hashed password

Is there a way i can hash the password when using Okta API to set password?
https://developer.okta.com/docs/reference/api/users/#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.
https://developer.okta.com/docs/reference/api/users/#create-user-with-password

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

Dragos,

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.

Dragos,

Thanks again for your help. We have had to abandon our approach of bulk import of bcrypted credentials, because it turns out our hashed passwords have an additional hashing step that makes them impossible to import directly into Okta.

So I am following up on your earlier suggestion to use the Password Import Inline hook. (Thanks!)

We’re using the Okta Java Management SDK (https://github.com/okta/okta-sdk-java) for access to the Okta API.

It seems to me that Create User with Password Import Inline Hook is not yet implemented in this SDK (either in a release or the current SNAPSHOT). Is that correct?

What’s the best way for us to use this API?

  • Direct HTTP call (not use the SDK)
  • Write a PR for the SDK
  • Something else I missed?

Hmm, I have realised that my posts have become increasingly off-topic. Sorry about that. Perhaps I should start another thread?

Hi @johnhurst

No worries regarding the replies. The Password Import Inline Hook feature is on the roadmap for the SDK, however we do not have an exact ETA at the moment.

If you would like to contribute to the SDK, I highly encourage you. Once this is done, one of my colleagues will review it and, if everything is good, it will be merged.

If you are time bounded, the best solution would be to go with direct http calls.

Experts !

I am new newbie here. Working on a project right now where I have a CSV file with passwords in HASH format from the source - Active Directory

  1. Is there anyway to import the CSV file into Okta without corrupting the existing passwords ?
  2. Is there anyway to extend schema objects for to store users with specific attributes ?

For now priority is migrate users with existing passwords to Okta from AD.

Inputs appreciated !
Sri

Hi @sriokta

Okta currently supports MD5, SHA-1, SHA-256, SHA-512 and BCRYPT for creating the users programatically via API. Active Directory uses a different hashing algorithm and, as such, the only way to import the users in Okta would be by setting up an application that uses Password Import Inline Hook.

Password Import Inline Hook works as follows:

  • Users are pre-created in Okta using the API call available here
  • Okta reaches to your web server with the user’s credentials
  • your web server takes the credentials, encrypts the password and checks them against the details from Active Directory
  • if the credentials are correct, the web server returns a success response - Okta will pick up this response and encrypt the user’s password in it’s database, dropping the need for any further requests to the web server
  • if the credentials are incorrect, the web server returns a failed response - Okta will pick up the response and will send any further credentials for the same user up until the result is success from the web server

Regarding extending the schema object, this can be easily done from Admin >> Directory/Users >> Profile Editor >> user >> Profile.

Hello Dragos,

Thanks for the detail !

I just came to know that users residing in IBM Tivoli DS. These need to be migrated to Okta. So, that said, I can ask for a CSV export along with user passwords which will be already in HASHED format.

Now, our main concern is with transitioning user password over a secure medium with zero chance of getting corrupted while migrating them to Okta.

Could you please advice on some best practices that can be implemented in this scenario.

highly appreciated !
sri