Factor Enrollment Flows

gistfile1.md

Factor, Provider Metadata

1. [Factors] (https://gist.github.com/srinivasanagandla-okta/0f2c0c8aa5dd1b9ed568)
2. [Providers] (https://gist.github.com/srinivasanagandla-okta/0f2c0c8aa5dd1b9ed568#list-providers)

Factor Enrollment Flows

Typical factor enrollment flow consists of the following:

1. Supply the profile information like PhoneNumber, TokenId etc using Enrollment API
2. Kick off Activation process which could result in generation/sending of activation/verification codes
3. User retrieves the verification codes from the device and those are sent to the Verification API
4. Server verifies the one-time information and activates the factor for the User.

Common Scenarios:

1. [Enroll, Activate, Verify Flow ==> For SMS kind of factors] (https://gist.github.com/srinivasanagandla-okta/ced563f86c8f477000ab)

• Call enroll API to add factor profile information
• Initiate Activation process which could generate/send the verification codes (one or more)
• Call Verify API to verify the codes from the User device
• If verification is successful then activate the factor
• At the end of verification stateToken can be exchanged for a sessionToken
• [Example flow] (https://gist.github.com/srinivasanagandla-okta/ced563f86c8f477000ab)

1. [Enroll, Verify Flow ==> For TOTP/HOTP ] (https://gist.github.com/srinivasanagandla-okta/10cbb5c8ce561a52902d)

• Call enroll API with profile information, this implicitly initiates the activation process
• Call verify API to verify the codes from the User device
• If verification is successful then activate the factor
• [Example flow] (https://gist.github.com/srinivasanagandla-okta/10cbb5c8ce561a52902d)

1. [Enroll and Poll ==> For Push ] (https://gist.github.com/srinivasanagandla-okta/452470c14e5850b36f69)

• Call enroll API with profile information (credentialID/UserId)
• Response has information about tasks need to be performed on the device (along with some kind of transactionId)
• Server activates the status of factor when it receives activated message from device with the same transactionId
• [Example flow] (https://gist.github.com/srinivasanagandla-okta/452470c14e5850b36f69)

1. [Verify & Activate ==> For Pre-provisioned Factor profiles] (https://gist.github.com/srinivasanagandla-okta/151376d3e5c8a69ff48c)

• Org Admin provisions user factors along with their profile information (could be an user profile import job or map to ldap)
• When User authenticates, he is prompted to activate the factor as his nextAction
• Once activation API is called, activation codes are sent to User's device
• Call Verify API to verify the codes from the User device
• If verification is successful then activate the factor
• [Example Flow] (https://gist.github.com/srinivasanagandla-okta/151376d3e5c8a69ff48c)

1. Enroll (Typical for Question Factor)

• Call enroll API with Question and Answer.
• Server activates the factor. No activation is required

Advanced Scenarios:

1. Enroll in Multiple Factors

• As part of authentication API response, list of factors to be enrolled are included with nextAction as "enroll"
• Each factor has to be enrolled, activated and verified through the APIs
• When all factors are enrolled, stateToken can be exchanged for a sessionToken

Factor Reset Flows

1. User resets the factor
2. Admin resets the factor

Disable/Deactivate Flows

1. Admin disables a factor across Org because of Service Disruption
2. Admin disables a factor for one or more Users