Hi! Do you have Active Directory anywhere in this mix? That is where Delegated Authentication would come into play and where Okta does not store the password, but rather delegates authentication to AD where the actual password is stored. Okta would only manage a hash in this scenario. If it is an Okta mastered account, then Okta would store the password.

As for a user where AD is not involved and the user is created via API, there are a couple of options. You could create the user with a password (like a temp default, etc) of course, if you create without creds, the user will receive an activation email which they will set themselves afterwards. If you utilize the former, Okta warns that you should not send a one-time to the users, but rather it would be on you to communicate that password to them and have them login with it for the first time.

Creating the user with a password is typical of a user registration flow, creating the user without is typical of creating the user in the admin UI.

Regardless, before the users can login to use the integrated application, they must have a way to login and presumably that would be a password (which in turn, would ensure they are "ACTIVE"). Would you mind elaborating more on the use case and what you are trying to achieve so we can help better provide a recommendation?

At this point I would say that even if the account was "ACTIVE", if the user didn't have a password then they couldn't login to utilize the app regardless, but I could be missing something. I hope this helps! Please do reply back with any questions or comments.

Thanks! I hope that helps!!