I’m a little confused by the expected flow for managing a user’s Okta Verify enrollment in OIE. For our existing use case we only allow users to manage their accounts (setting username/password and removing/adding Okta Verify enrollments) through one of our custom applications. We have been using the factors API at /api/v1/users/{userId}/factors to list, enroll, verify, and delete factors from users
I believe this means we should be interacting with the authenticators API at /api/v1/users/{userId}/authenticator-enrollments rather than interacting with factors for OIE.
Am I understanding this correctly? If so, that /authenticator-enrollments endpoint does not provide any way to enroll a user in a new authenticator as far as I can tell? Are we meant to use the IDX flow to enroll authenticators for existing users?
Further, in OIE, multiple Okta Verify enrollments are now supported whereas in classic only one was supported. See:
All of this further leads me to believe we are meant to move away from the factors API? In my testing it seems you cannot add multiple factors of the same type, I receive the following error when attempting to add a second PUSH enrollment via the factors API for example:
Maximum number of enrollments reached for factorType push.
If this is the case, I am struggling to find documentation on the correct method for adding authenticator enrollments to existing users. I see 4 options currently:
1. Use the factors API
This does not seem feasible or correct to me per reasons stated above
2. Use the IDX interaction flow
I have not been able to find any clear documentation on using this for account management for existing users. What I have found related to this seems to indicate this might be possible if the user has authenticated via the IDX interaction flow but this is not how we are authenticating users to our application.
I do not see any endpoints here for enrolling a new authenticator for a user. The App Authenticators section of this API does seem to support enrollment but it explicitly states it is for custom authenticators only, so no Okta Verify I believe? The Authenticators section of this API does not include any direct path to enroll as far I see, just list or retrieve. I do see that listing the authenticators for a user could return an enroll link in the response, but in my testing all the authenticators for my users return a value of enroll: false with no enroll link.
4. Use the Sign-in Experience Management End User Enrollment API
This option requires the user to be redirected to an Okta domain to set up the authenticator which defeats our requirement of only permitting the enrollment within our custom application.
The core problem is a transition from the Okta Classic model to the Okta Identity Engine (OIE), which has changed how multi-factor authentication (MFA) is managed:
In Okta Classic: Factors API (/api/v1/users/{userId}/factors) User Factors . Only supports a single enrollment per factor type.
In OIE: Authenticators API (/api/v1/users/{userId}/authenticator-enrollments) User Authenticator Enrollments . This endpoint is primarily for listing, retrieving, and deleting existing authenticator enrollments and supports multiple enrollments of the same authenticator type.
Thanks for the information, it sounds like my assumption was correct that for OIE we’re meant to be moving away from the Factors API. I did read through that Understand authenticator enrollment policy API changes after the upgrade link you sent which was what originally lead me to that thought but I wasn’t 100% sure that I was coming away with the correct conclusion.
I have tried to use the IDX flow for this but I have been unable to get an IDK interaction started for the user that seems viable for managing an existing user, in the testing I’ve done with it thus far I’ve only been able to get a response back with an intent of LOGIN whereas when I inspect the response when setting up Okta Verify from the Okta Dashboard it seems the intent value for that response is CREDENTIAL_ENROLLMENT. I have been working off the Okta IDX Java library as it is more relevant to our use case but the AuthJS version seems to have more documentation, I will see if I can find what I need there and adapt it to Java.