reset factors by username via the API? 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:

reset factors by username via the API?

I am trying to expand okta MFA usage in my org. As part of that effort, I need to give my help desk a method to reset users' MFA factors. Our help desk is a fairly fluid group, so I am hoping to avoid having to grant them all admin access by creating a tool that leverages the API to do this. In looking at the api docs, it seems like reseting factors is only possible via UID, so the logic would have to be:
  • look up UID by username
  • look up factorID's by UID
  • reset factorID's by UID
Has anyone attempted something similar? 
Raja NejemRaja Nejem (Okta, Inc.)
It might be easier to 1) get user id   2) reset all factors
You can reset individual factors, however, if the end user can access the Okta portal, they can reset their own factors.

API to reset all factors:
Raja NejemRaja Nejem (Okta, Inc.)
You can also reset MFA from the Okta admin portal.  You would have to make the help desk staff part of the Okta admins.
Thanks Raja - question about an end user reseting their own factors. Shouldn't a user need to be able to verify their factor before they can self reset it? So if a user loses his/her phone, and as a result can't satify the Okta Verify push challenge, they should not be able to reset their factors. Do I have this wrong? 
Raja NejemRaja Nejem (Okta, Inc.)
You can set up multiple factors that a user can use.  Example, SMS and Okta Push Verify.  If a user configured both thes options, they can log in with either one.  From there, they can go to their settings and reset the other factor.
api-workday api-workdayapi-workday api-workday
Hi Mark,

Have been faced with the same dilemma.

Here is what we do now and where we will be going.

MFA enrollment guidelines strongly encourage our users to enroll multiple factors. The point here is that if at all possible we want to avoid the need for an administrative reset of factors.  As Raja points out if i enroll for SMS and loose my phone and along with it okta verify (OTP or push) as soon as I get the phone back I can leverage SMS to self re-enroll verify.  This isn't perfect but certainly helps in most cases.  Now that MFA enrollment policies are available we are going to be revisiting a number of things specifically forcing users to enroll for both SMS and Okta verify if they have a company issued phone.

We identified a handful of our similarly fluid service desk agents that we would allow to perform factor resets.  We didn't have to grant them full admin privleges in Okta but they are User admins. To accompany this reset we realize that calling the service desk to reset a factor could very well be the thing that allows a bad guy to circumvent our strong authentication policies.  We have provided a very brief KBA (knowledge based authentication) quiz for our service desk agents to perform prior to the reset of the password.  First and foremost they are to see if the user has an additional factor available to perform the reset and if available they are to walk the user through a self reset. As needed they are allowed to reset the factors for the user and upon completion notify the user and the users manager of the action as a means of abuse detection. We audit the resets and compare them with tickets. Right now this is a manual control.

Looking forward we will most likely be integrating the password reset into our service-now workflow using the API.  As you point out you have to have the uid and if you are trying to be granular you have to have the factorid. This does turn into a multiple api call reset but it will be worth it in the long run.  I've modeled out the reset flow in my powershell module (oktaResetFactorsbyUser for example which will resolve a username to uid).  The intent is to wrap the reset from the service-now which forces the agent to perform a comprehensive user verification process (series of dynamic KBA questions).

Looking a little further forward I have a longer term strategy that will include every user having a yubikey or similar physical token assigned between the phone factors (sms and okta verify) and the token factor i am hoping the need for admin resets on factors goes away.

on a different topic that is slightly related. As soon as i've got the factor reset process wrapped up in service-now we are going to have a v2 version of the process that is intended to assist the users in the case of a lost password. If the agent calls the service desk with a forgotten password but they have an enrolled factor (sms, verify otp, push, token (yk) otp) we will have the agent trigger/collect the verification (verify using the factors API) before proceeding. I know this is a feature available within Okta and we have it enabled, the problem is most users don't enroll or if they do they don't rememeber and they end up calling the service desk anyway.  The need for this will go away when okta merges the MFA and password reset factors (roadmap item).  

Sorry for the novella,