Delegated authentication - Password caching? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Jake MowrerJake Mowrer 

Delegated authentication - Password caching?


In a scenario where I have delegated authentication configured, I had an incident where my domain controllers were not available yet my users were still able to log in, even when directly going to the SaaS app (O365 in this case).  Can someone explain how this would still work even when all my DCs are down?

Aaron YeeAaron Yee (Okta, Inc.)
Hi Jake,

Thanks for your inquiry. Good question! To mitigate problems of your directory connecting to Okta, we internally persist your directory authenticated (DelAuth) session. This helps in many scenarios - when all DCs go down (as you mentioned), when all Okta AD agents go down, or when connectivity drops.

To ensure system availability and customer access to apps, we store a one-way irreversible hash (SHA-256) of user ID, username, and password from prior DelAuth requests. This is not the hash stored by AD. It's a separate hash that's calculated by and only used within Okta. The hashed session data is cached in our database for 10 days and is valid for authentication for 5 days.

The next time the user logs in, Okta checks the connection to AD.
  • If available, Okta delegates authentication to the directory. If successful, we update the cached session data and the time stamp. DelAuth requests proceed as normal.
  • If the connection is NOT available, Okta authenticates to the cached session for the remaining time of the 5 day period.