The Okta Authentication API provides operations to authenticate users, perform multifactor enrollment and verification, recover forgotten passwords, and unlock accounts. It can be used as a standalone API to provide the identity layer on top of your existing application, or it can be integrated with the Okta Sessions API to obtain an Okta session cookie and access apps within Okta.
The API is targeted for developers who want to build their own end-to-end login experience to replace the built-in Okta login experience and addresses the following key scenarios:
- Primary authentication allows you to verify username and password credentials for a user.
- Multifactor authentication (MFA) strengthens the security of password-based authentication by requiring additional verification of another Factor such as a temporary one-time password or an SMS passcode. The Authentication API supports user enrollment with MFA factors enabled by the administrator, as well as MFA challenges based on your global session policy.
- Recovery allows users to securely reset their password if they've forgotten it, or unlock their account if it has been locked out due to excessive failed login attempts. This functionality is subject to the security policy set by the administrator.
Application types
The behavior of the Okta Authentication API varies depending on the type of your application and your org's security policies such as the global session policy, the MFA Enrollment Policy, or the Password Policy.
Note: Policy evaluation is conditional on the client request context such as IP address.
Note: In Identity Engine, the Multifactor (MFA) Enrollment Policy name has changed to authenticator enrollment policy.
Public application
A public application is an application that anonymously starts an authentication or recovery transaction without an API token, such as the Okta Sign-In Widget. Public applications are aggressively rate-limited to prevent abuse and require primary authentication to be successfully completed before releasing any metadata about a user.
Trusted application
Trusted applications are backend applications that act as authentication broker or login portal for your Okta organization and may start an authentication or recovery transaction with an administrator API token. Trusted apps may implement their own recovery flows and primary authentication process and may receive additional metadata about the user before primary authentication has successfully completed.
Note: Trusted web applications may need to override the client request context to forward the originating client context for the user.
Get started with authentication
Make sure that you need the API. Check out the Okta Sign-In Widget which is built on the Authentication API. The Sign-In Widget is easier to use and supports basic use cases.
For more advanced use cases, learn the Okta API basics.
Explore the Authentication API:
(opens new window)
Authentication operations
Primary authentication
POST /api/v1/authn
Every authentication transaction starts with primary authentication which validates a user's primary password credential. Password Policy, MFA Policy, and Sign-On Policy are evaluated during primary authentication to determine if the user's password is expired, a Factor should be enrolled, or additional verification is required. The transaction state of the response depends on the user's status, group memberships and assigned policies.
Note: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.
The requests and responses vary depending on the application type, and whether a password expiration warning is sent:
- Primary Authentication with Public Application—Request Example
- Primary Authentication with Trusted Application—Request Example
- Primary Authentication with Activation Token—Request Example
- Primary Authentication with Device Fingerprinting—Request Example
- Primary Authentication with Password Expiration Warning—Request Example
Note: You must first enable MFA factors and assign a valid Sign-On Policy to a user to enroll and/or verify a MFA Factor during authentication.
Request parameters for primary authentication
As part of the authentication call either the username and password or the token parameter must be provided.
audience Deprecated | App ID of the target app the user is signing into | Body | String | FALSE | |
context | Provides additional context for the authentication transaction | Body | Context object | FALSE | |
options | Opt-in features for the authentication transaction | Body | Options object | FALSE | |
password | User's password credential | Body | String | FALSE | |
token | Token received as part of activation user request | Body | String | FALSE | |
username | User's non-qualified short-name (for example: dade.murphy) or unique fully-qualified sign in name (for example: ) | Body | String | FALSE |
The authentication transaction state machine can be modified via the following opt-in features:
multiOptionalFactorEnroll | Transitions transaction back to MFA_ENROLL state after successful Factor enrollment when additional optional factors are available for enrollment | Boolean | TRUE | FALSE | FALSE |
warnBeforePasswordExpired | Transitions transaction to PASSWORD_WARN state before SUCCESS if the user's password is about to expire and within their password policy warn period | Boolean | TRUE | FALSE | FALSE |
The context object allows trusted web applications such as an external portal to pass additional context for the authentication or recovery transaction.
Note: Overriding context such as deviceToken is a highly privileged operation limited to trusted web applications and requires making authentication or recovery requests with a valid administrator API token. If an API token is not provided, the deviceToken will be ignored.
deviceToken | A globally unique ID identifying the user's client device or user agent | String | TRUE | FALSE | FALSE | 32 |
Device Token best practicesNote: You must always pass the same deviceToken for a user's device with every authentication request for per-device or per-session Sign-On Policy Factor challenges. If the deviceToken is absent or does not match the previous deviceToken, the user is challenged every-time instead of per-device or per-session.
Similarly, you must always pass the same deviceToken for a user's device with every authentication request for new device security behavior detection. If the deviceToken is absent or doesn't match a recent deviceToken for the user, the request is considered to be from a new device. See New Device Behavior Detection (opens new window).
Use the following recommendations as guidelines for generating and storing a deviceToken for both web and native applications.
Web apps
Okta recommends that you generate a UUID or GUID for each client and persist the deviceToken using a secure, HTTP-only cookie or HTML5 localStorage scoped to the customer's domain as the default implementation. See Cookie flags that matter
(opens new window) for more best practices on hardening HTTP cookies.
Native apps
Ask the device operating system for a unique device ID. See Apple's information on DeviceCheck (opens new window) for an example.
Response parameters
Authentication Transaction object with the current state for the authentication transaction
401 Unauthorized status code is returned for requests with invalid credentials, locked out accounts or access denied by sign-on policy.
429 Too Many Requests status code may be returned when the rate-limit is exceeded.
Primary authentication with public application
Authenticates a user with username/password credentials via a public application
Request example for primary authentication with public application Response example for primary authentication with public application (success)Users with a valid password not assigned to a Sign-On Policy with additional verification requirements will successfully complete the authentication transaction.
Response example for primary authentication with public application (invalid credentials)401 Unauthorized status code is returned for requests with invalid credentials or when access is denied based on sign-on policy.
Response example for primary authentication with public application (locked out)Primary authentication requests for a user with LOCKED_OUT status is conditional on the user's password policy. Password policies define whether to hide or show lockout failures which disclose a valid user identifier to the caller.
Response example for primary authentication with public application and hide lockout failures (Default)If the user's password policy is configured to hide lockout failures, a 401 Unauthorized error is returned preventing information disclosure of a valid user identifier.
Response example for primary authentication with public application and show lockout failuresIf the user's password policy is configure to show lockout failures, the authentication transaction completes with LOCKED_OUT status.
Response example for primary authentication with public application and expired passwordUser must change their expired password to complete the authentication transaction.
Response example for primary authentication with public application (Factor challenge)Note: Users are challenged for MFA (MFA_REQUIRED) before PASSWORD_EXPIRED if they have an active Factor enrollment.
User is assigned to a Sign-On Policy that requires additional verification and must select and verify a previously enrolled Factor by id to complete the authentication transaction.
Response example for primary authentication with public application (Factor enroll)User is assigned to a MFA Policy that requires enrollment during sign-in and must select a Factor to enroll to complete the authentication transaction.
Note: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.
Primary authentication with trusted application
Authenticates a user through a trusted application or proxy that overrides the client request context
Notes:
- Specifying your own deviceToken is a highly privileged operation limited to trusted web applications and requires making authentication requests with a valid API token. If an API token is not provided, the deviceToken will be ignored.
- The public IP address of your trusted application must be allowed as a gateway IP address to forward the user agent's original IP address with the X-Forwarded-For HTTP header.
Primary authentication with activation token
Authenticates a user through a trusted application or proxy that overrides the client request context
Notes:
- Specifying your own deviceToken is a highly privileged operation limited to trusted web applications and requires making authentication requests with a valid API token. If an API token is not provided, the deviceToken is ignored.
- The public IP address of your trusted application must be allowed as a gateway IP address to forward the user agent's original IP address with the X-Forwarded-For HTTP header.
- The Authorization: SSWS ${api_token} header is optional, in case of a SPA (Single Page app) this header can be omitted.
In the case where the user was created without credentials the response will trigger the workflow to set the user's password. After the password is configured, depending on the MFA setting, the workflow continues with MFA enrollment or a successful authentication completes.
Response example for activation token (failure - invalid or expired token)Primary authentication with device fingerprinting
Include the X-Device-Fingerprint header to supply a device fingerprint. The X-Device-Fingerprint header is used in the following ways:
- If the new or unknown device email notification is enabled, an email is sent to the user if the device fingerprint sent in the X-Device-Fingerprint header isn't associated with a previously successful user sign in. For more information about this feature, see the General Security documentation (opens new window).
- If you have the security behavior detection feature enabled and you have a new device behavior configured in a policy rule, a new device is detected if the device fingerprint sent in the X-Device-Fingerprint header isn't associated with a previously successful user sign in. See New Device Behavior Detection (opens new window).
Note: The use of the X-Device-Fingerprint header for new device security behavior detection is deprecated. Starting April 12 2021, we are going to enable improvements to the new device security behavior (opens new window) for all the existing tenants. After the improvements are rolled out, new device security behavior only relies on the deviceToken in the Context Object and doesn't rely on the X-Device-Fingerprint header. The new or unknown device email notification feature continues to rely on the X-Device-Fingerprint header.
Specifying your own device fingerprint in the X-Device-Fingerprint header is a highly privileged operation that is limited to trusted web applications and requires making authentication requests with a valid API token. You should send the device fingerprint only if the trusted app has a computed fingerprint for the end user's client.
Device fingerprint best practicesNote: The X-Device-Fingerprint header is different from the device token. Device-based MFA in the Okta Sign-On policy rules depends on the device token only and not on the X-Device-Fingerprint header. See Context Object for more information on the device token. Device-based MFA would work only if you pass the device token in the client request context.
Use the following recommendations as guidelines for generating and storing a device fingerprint in the X-Device-Fingerprint header for both web and native applications.
Web apps
Okta recommends using a secure, HTTP-only cookie with a random/unique value on the customer's domain as the default implementation. See
Cookie flags that matter (opens new window) for more best practices on hardening HTTP cookies.
Native apps
Ask the device operating system for a unique device ID. See Apple's information on DeviceCheck
(opens new window) for an example.
Primary authentication with password expiration warning
Authenticates a user with a password that is about to expire. The user should change their password to complete the authentication transaction but can choose to skip it.
Notes:
- The warnBeforePasswordExpired option must be explicitly specified as true to allow the authentication transaction to transition to PASSWORD_WARN status.
- Non-expired passwords successfully complete the authentication transaction if this option is omitted or is specified as false.
SP-initiated step-up authentication
Early Access
Notes:
- This endpoint is currently supported only for SAML-based apps.
- You must first enable the custom sign-in page for the application before using this API.
Note: Enabling the custom sign-in page for an application is only available with Okta Classic Engine. See Identity Engine limitations.
Every step-up transaction starts with the user accessing an application. If step-up authentication is required, Okta redirects the user to the custom sign-in page with state token as a request parameter.
For example, if the custom sign-in page is set as //login.example.com, then Okta will redirect to //login.example.com?stateToken=<token>. To determine the next step, check the state of the transaction.
- Step-up authentication without Okta session
- Step-up authentication with Okta session
Step-up authentication without Okta session
Request example for step-up authentication without Okta session (get transaction state) Response example for step-up authentication without Okta session Request example for step-up authentication without Okta session (perform primary authentication)Primary authentication has to be completed by using the value of stateToken request parameter passed to custom sign-in page.
Response example for step-up authentication without Okta session when MFA isn't requiredNote: Global session policy and the related authentication policy are evaluated after successful primary authentication.
Note: Sign in to the app by following the next link relation.
Step-up authentication with Okta session
Request example to get transaction state for step-up authentication with Okta session Response example for Factor enroll for step-up authentication with Okta sessionThe user is assigned to an MFA Policy that requires enrollment during the sign-in process and must select a Factor to enroll to complete the authentication transaction.
Response example for Factor challenge for step-up authentication with Okta sessionNote: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.
User is assigned to a global session policy or an authentication policy that requires additional verification and must select and verify a previously enrolled Factor by id to complete the authentication transaction.
Response example after authentication and MFA are complete for step-up authentication with Okta sessionNote: Sign in to the app by following the next link relation.
IDP-initiated step-up authentication
POST /api/v1/authn
Early Access
Authenticates a user for signing in to the specified application
Notes:
- Only WS-Federation, SAML based apps are supported.
- Pass the application instance ID of the app as "audience" along with the user credentials.
Note: audience is a Deprecated parameter.
Request example for IDP-initiated step-up authenticationNote: Okta Sign-on Policy and the related App Sign-on Policy are evaluated after successful primary authentication.
Response example when MFA isn't requiredNote: audience is a Deprecated parameter.
Response example for Factor enrollNote: Sign in to the app by following the next link relation.
The user is assigned to an MFA Policy that requires enrollment during the sign-in process and must select a Factor to enroll to complete the authentication transaction.
Response example for Factor challengeNote: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.
User is assigned to a Sign-on Policy or App Sign-on Policy that requires additional verification and must select and verify a previously enrolled Factor by id to complete the authentication transaction.
Response example for invalid or unknown application Response example for unsupported applicationChange password
POST /api/v1/authn/credentials/change_password
Changes a user's password by providing the existing password and the new password for authentication transactions with either the PASSWORD_EXPIRED or PASSWORD_WARN state
This operation provides an option to revoke all the sessions of the specified user, except for the current session, if the endpoint is called by the user.
- A user must change their expired password for an authentication transaction with PASSWORD_EXPIRED status to successfully complete the transaction.
- A user may opt-out of changing their password (skip) when the transaction has a PASSWORD_WARN status.
Request parameters for change password
newPassword | New password for user | Body | String | TRUE | |
oldPassword | User's current password that is expired or about to expire | Body | String | TRUE | |
revokeSessions | When set to true, revokes all user sessions, except for the current session | Body | boolean | FALSE | FALSE |
stateToken | state token for the current transaction | Body | String | TRUE |
Response parameters for change password
Authentication Transaction object with the current state for the authentication transaction
If the oldPassword is invalid you receive a 403 Forbidden status code with the following error:
If the newPassword does not meet password policy requirements, you receive a 403 Forbidden status code with the following error:
Request example for change password Response example for change passwordMultifactor Authentication operations
You can enroll, activate, manage, and verify factors inside the authentication context with /api/v1/authn/factors.
Note: You can enroll, manage, and verify factors outside the authentication context with /api/v1/users/:uid/factors/.
Enroll Factor
POST /api/v1/authn/factors
CORS
Enrolls a user with a Factor assigned by their MFA Policy
Note: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.
- Enroll Okta Security Question Factor
- Enroll Okta SMS Factor
- Enroll Okta Call Factor
- Enroll Okta Email Factor
- Enroll Okta Verify TOTP Factor
- Enroll Okta Verify Push Factor
- Enroll Google Authenticator Factor
- Enroll RSA SecurID Factor
- Enroll Symantec VIP Factor
- Enroll YubiKey Factor
- Enroll Duo Factor
- Enroll U2F Factor
- Enroll WebAuthn Factor
- Enroll Custom HOTP Factor
Note: This operation is only available for users that have not previously enrolled a Factor and have transitioned to the MFA_ENROLL state.
Request parameters for enroll Factor
factorType | type of Factor | Body | Factor Type | TRUE |
profile | profile of a supported Factor | Body | Factor Profile object | TRUE |
provider | Factor provider | Body | Provider Type | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Response parameters for enroll Factor
Authentication Transaction object with the current state for the authentication transaction
Note: Some Factor types require activation to complete the enrollment process. The authentication transaction transitions to MFA_ENROLL_ACTIVATE if a Factor requires activation.
Enroll Okta Security Question Factor
Enrolls a user with the Okta question Factor and question profile
Request example for enroll Okta Security Question Factor Response example for enroll Okta Security Question FactorNote: The Security Question Factor doesn't require activation and is ACTIVE after enrollment.
Enroll Okta SMS Factor
Enrolls a user with the Okta sms Factor and an SMS profile. A text message with an OTP is sent to the device during enrollment and must be activated by following the next link relation to complete the enrollment process.
Request example for enroll Okta SMS Factor Response example for enroll Okta SMS Factor Resend SMS as part of enrollmentUse the resend link to send another OTP if the user doesn't receive the original activation SMS OTP.
Request example for resend SMSNotes: The current rate limit is one SMS challenge per device every 30 seconds.
Okta round-robins between SMS providers with every resend request to help ensure delivery of SMS OTP across different carriers.
Enroll Okta Call Factor
Enrolls a user with the Okta call Factor and a Call profile. A voice call with an OTP is sent to the device during enrollment and must be activated by following the next link relation to complete the enrollment process.
Request example for enroll Okta Call Factor Response example for enroll Okta Call Factor Resend voice call as part of enrollmentUse the resend link to send another OTP if the user doesn't receive the original activation Voice Call OTP.
Request example for resend voice callNotes: The current rate limit is one voice call challenge per device every 30 seconds.
Okta round-robins between voice call providers with every resend request to help ensure delivery of voice call OTP across different carriers.
Enroll Okta Email Factor
Enrolls a user with the Okta email Factor using the user's primary email address. An email message with an OTP is sent to the user during enrollment and must be activated by following the next link relation to complete the enrollment process.
Request example for enroll Okta Email Factor Response example for enroll Okta Email Factor Resend email as part of enrollmentUse the resend link to send another OTP if user doesn't receive the original activation email OTP.
Request example for resend emailEnroll Okta Verify TOTP Factor
Enrolls a user with the Okta token:software:totp Factor. The Factor must be activated after enrollment by following the next link relation to complete the enrollment process.
Request example for enroll Okta Verify TOTP Factor Response example for enroll Okta Verify TOTP FactorNote: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.
Enroll Okta Verify Push Factor
Enrolls a user with the Okta verify push Factor. The Factor must be activated on the device by scanning the QR code or visiting the activation link sent via email or sms.
Use the published activation links to embed the QR code or distribute an activation email or sms.
Request example for enroll Okta Verify Push Factor Response example for enroll Okta Verify Push FactorNote: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.
Enroll Google Authenticator Factor
Enrolls a user with the Google token:software:totp Factor. The Factor must be activated after enrollment by following the next link relation to complete the enrollment process.
Request example for enroll Google Authenticator factor Response example for enroll Google Authenticator factorEnroll RSA SecurID factor
Enrolls a user with an RSA SecurID factor and a token profile. RSA tokens must be verified with the current pin+passcode as part of the enrollment request.
Request example for enroll RSA SecurID Factor Response example for enroll RSA SecurID FactorEnroll Symantec VIP Factor
Enrolls a user with a Symantec VIP Factor and a token profile. Symantec tokens must be verified with the current and next passcodes as part of the enrollment request.
Request example for enroll Symantec VIP Factor Response example for enroll Symantec VIP FactorEnroll YubiKey Factor
Enrolls a user with a Yubico Factor (YubiKey). YubiKeys must be verified with the current passcode as part of the enrollment request.
Request example for enroll YubiKey Factor Response example for enroll YubiKey FactorEnroll Duo Factor
The enrollment process starts with an enrollment request to Okta, then continues with the Duo widget that is embedded in the page. The page needs to create an iframe with the name duo_iframe (described in the Duo documentation (opens new window)) to host the widget. The script address is received in the response object in \_embedded.factor.\_embedded.\_links.script object. The information to initialize the Duo object is taken from \_embedded.factor.\_embedded.activation object as it is shown in the full example. To maintain the link between Duo and Okta, the stateToken must be passed back when Duo calls the callback. This is done by populating the hidden element in the "duo_form" as it is described here (opens new window). After Duo enrollment and verification is done, the Duo script makes a call back to Okta. To complete the authentication process, make a call using the poll link to get session token and verify successful state.
Request example for enroll Duo Factor Response example for enroll Duo FactorFull page example for Duo enrollment
In this example we put all of the elements together in the html page.
Activation poll request exampleVerifies successful authentication and obtains a session token
Activation poll response exampleEnroll U2F Factor
Enrolls a user with a U2F Factor. The enrollment process starts with getting an appId and nonce from Okta and using those to get registration information from the U2F key using the U2F javascript API.
Enroll U2F request example Enroll U2F response exampleNote: The appId property in Okta U2F enroll/verify API response is the origin (opens new window) of the web page that triggers the API request (assuming that the origin has been configured to be trusted by Okta). According to the FIDO spec (opens new window), enrolling and verifying a U2F device with appIds in different DNS zones is not allowed. For example, if a user enrolled a U2F device via the Okta Sign-In Widget that is hosted at //login.company.com, while the user can verify the U2F Factor from //login.company.com, the user would not be able to verify it from Okta portal //company.okta.com. The U2F device would return error code 4 - DEVICE_INELIGIBLE.
Enroll WebAuthn Factor
Note: The WebAuthN Factor is available for those using the Style the Okta-hosted Sign-In Widget. If you are using a self-hosted, customized sign-in widget, you must first upgrade to widget version 3.4.0 and enable the configuration option (opens new window).
Enrolls a user with a WebAuthn Factor. The enrollment process starts with getting the WebAuthn credential creation options, which are used to help select an appropriate authenticator using the WebAuthn API. This authenticator then generates an enrollment attestation that may be used to register the authenticator for the user.
Enroll WebAuthn request parametersstateToken | state token for the current transaction | Body | String | TRUE |
In the embedded resources object, the factor._embedded.activation object contains properties used to guide the client in creating a new WebAuthn credential for use with Okta.
For more information about these credential creation options, see the WebAuthn spec for PublicKeyCredentialCreationOptions (opens new window).
Enroll WebAuthn request example Enroll WebAuthn response exampleNote: Additionally, the activation object contains a u2fParams object with an appid property. This deprecated legacy property was used to support backwards compatibility with U2F and is no longer in use.
Enroll Custom HOTP Factor
Enrollment via the Authentication API is currently not supported for Custom HOTP Factor. Please refer to the Factors API documentation if you would like to enroll users for this type of Factor.
Activate Factor
POST /api/v1/authn/factors/${factorId}/lifecycle/activate
CORS
The sms,call, and token:software:totp Factor types require activation to complete the enrollment process.
- Activate TOTP Factor
- Activate SMS Factor
- Activate Call Factor
- Activate Email Factor
- Activate Push Factor
- Activate U2F Factor
- Activate WebAuthn Factor
Activate TOTP Factor
Activates a token:software:totp Factor by verifying the OTP
Request parameters for activate TOTP FactorNote: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.
factorId | id of Factor returned from enrollment | URL | String | TRUE |
passCode | OTP generated by device | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the passcode is invalid, you receive a 403 Forbidden status code with the following error:
Activate TOTP request example Activate TOTP response exampleActivate SMS Factor
Activates an sms Factor by verifying the OTP. The request and response is identical to activating a TOTP Factor
Activate SMS Factor request parametersfactorId | id of Factor returned from enrollment | URL | String | TRUE |
passCode | OTP sent to mobile device | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the passcode is invalid, you receive a 403 Forbidden status code with the following error:
Activate SMS Factor request example Activate SMS Factor response exampleActivate Call Factor
Activates a call Factor by verifying the OTP. The request and response is identical to activating a TOTP Factor
Activate Call Factor request parametersfactorId | id of Factor returned from enrollment | URL | String | TRUE |
passCode | Passcode received via the voice call | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the passcode is invalid, you receive a 403 Forbidden status code with the following error:
Activate Call Factor request example Activate Call Factor response exampleActivate Email Factor
Activates an email Factor by verifying the OTP. The request and response are identical to activating a TOTP Factor
Activate Email Factor request parametersfactorId | id of factor returned from enrollment | URL | String | TRUE |
passCode | Passcode received via the email message | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction.
If the passcode is invalid, you receive a 403 Forbidden status code with the following error:
Activate Email Factor request example Activate Email Factor response exampleActivate Push Factor
Activation of push factors are asynchronous and must be polled for completion when the factorResult returns a WAITING status.
Activations have a short lifetime (minutes) and TIMEOUT if they are not completed before the expireAt timestamp. Use the published activate link to restart the activation process if the activation is expired.
Activate Push Factor request parametersfactorId | id of Factor returned from enrollment | URL | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
Activate Push Factor request example Activate Push Factor response example (waiting)Activate Push Factor response example (success) Activate Push Factor response example (timeout)Note: Follow the the published next link to keep polling for activation completion.
Poll for Push Factor activationNote: Follow the the published activate link to restart the activation process.
After the push notification is sent to the user's device, we need to know when the user completes the activation. This is done by polling the "poll" link.
Poll for Push request example Poll for Push response example Send activation linksSends an activation email or SMS when the user is unable to scan the QR code provided as part of an Okta Verify transaction. If for any reason the user can't scan the QR code, they can use the link provided in email or SMS to complete the transaction.
Send activation links request example (email) Send activation links request example (SMS) Send activation links response exampleNote: The user must click the link from the same device as the one where the Okta Verify app is installed.
Activate U2F Factor
Activation gets the registration information from the U2F token using the API and passes it to Okta.
Get registration information from U2F token by calling the U2F JavaScript library methodActivate a u2f Factor by verifying the registration data and client data.
Activate U2F request parametersclientData | base64-encoded client data from U2F javascript call | Body | String | TRUE |
factorId | id of Factor returned from enrollment | URL | String | TRUE |
registrationData | base64-encoded registration data from U2F javascript call | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the registration nonce is invalid or if registration data is invalid, you receive a 403 Forbidden status code with the following error:
Activate U2F request example Activate U2F response exampleActivate WebAuthn Factor
Activation gets the registration information from the WebAuthn assertion using the API and passes it to Okta.
Get registration information from WebAuthn assertion by calling the WebAuthn JavaScript libraryActivate a webauthn Factor by verifying the attestation and client data.
Activate WebAuthn request parametersattestation | base64-encoded attestation from the WebAuthn javascript call | Body | String | TRUE |
clientData | base64-encoded client data from the WebAuthn javascript call | Body | String | TRUE |
factorId | id of Factor returned from enrollment | URL | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the attestation nonce is invalid, or if the attestation or client data are invalid, you receive a 403 Forbidden status code with the following error:
Activate WebAuthn request example Activate WebAuthn response exampleVerify Factor
Verifies an enrolled Factor for an authentication transaction with the MFA_REQUIRED or MFA_CHALLENGE state
- Verify Security Question Factor
- Verify SMS Factor
- Verify Call Factor
- Verify TOTP Factor
- Verify Push Factor
- Verify Duo Factor
- Verify U2F Factor
- Verify WebAuthn Factor
Note: If the sign-on (or app sign-on) policy allows remembering the device, then the end user should be prompted to choose whether the current device should be remembered. This helps reduce the number of times the user is prompted for MFA on the current device. The user's choice should be passed to Okta using the request parameter rememberDevice to the verify endpoint. The default value of rememberDevice parameter is false.
Verify Security Question Factor
POST /api/v1/authn/factors/${factorId}/verify
CORS
Verifies an answer to a question Factor
Request parameters for verify Security Question Factoranswer | answer to security question | Body | String | TRUE |
factorId | id of Factor | URL | String | TRUE |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the answer is invalid you receive a 403 Forbidden status code with the following error:
Request example for verify Security Question Factor Response example for verify Security Question FactorVerify SMS Factor
POST /api/v1/authn/factors/${factorId}/verify
CORS
Request parameters for verify SMS FactorfactorId | id of Factor | URL | String | TRUE |
passCode | OTP sent to device | Body | String | FALSE |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
stateToken | state token for the current transaction | Body | String | TRUE |
Response parameters for verify SMS FactorNote: If you omit passCode in the request, a new OTP is sent to the device, otherwise the request attempts to verify the passCode.
Authentication Transaction object with the current state for the authentication transaction
If the passCode is invalid, you receive a 403 Forbidden status code with the following error:
Send SMS challenge (OTP)Omit passCode in the request to send an OTP to the device.
Request example for send SMS challenge (OTP) Response example for send SMS challenge (OTP) Resend SMS challengeUse the resend link to send another OTP if the user doesn't receive the original SMS OTP.
Request example for resend SMS Verify SMS challenge (OTP)Notes: The current rate limit is one SMS challenge per device every 30 seconds.
Okta round-robins between SMS providers with every resend request to help ensure delivery of SMS OTP across different carriers.
Specify passCode in the request to verify the Factor.
Request example for verify SMS challenge (OTP) Response example for verify SMS challenge (OTP)Verify Call Factor
POST /api/v1/authn/factors/${factorId}/verify
CORS
Request parameters for verify Call FactorfactorId | id of Factor | URL | String | TRUE |
passCode | OTP sent to device | Body | String | FALSE |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
stateToken | state token for the current transaction | Body | String | TRUE |
Response parameters for verify Call FactorNote: If you omit passCode in the request, a new OTP is sent to the device, otherwise the request attempts to verify the passCode.
Authentication Transaction object with the current state for the authentication transaction
If the passCode is invalid, you receive a 403 Forbidden status code with the following error:
Send Voice Call challenge (OTP)Omit passCode in the request to send an OTP to the device.
Request example for send Voice Call challenge (OTP) Response example for send Voice Call challenge (OTP) Resend voice call challengeUse the resend link to send another OTP if the user doesn't receive the original Voice Call OTP.
Request example for resend voice call Verify Call challenge (OTP)Notes: The current rate limit is one voice call challenge per device every 30 seconds.
Okta round-robins between voice call providers with every resend request to help ensure delivery of voice call OTP across different carriers.
Specify passCode in the request to verify the Factor.
Request example for verify Call challenge Response example for verify Call challengeVerify TOTP Factor
POST /api/v1/authn/factors/${factorId}/verify
CORS
Verifies an OTP for a token:software:totp or token:hotp Factor
Request parameters for verify TOTP FactorNote: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.
factorId | id of Factor | URL | String | TRUE |
passCode | OTP sent to device | Body | String | FALSE |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
stateToken | state token for the current transaction | Body | String | TRUE |
Authentication Transaction object with the current state for the authentication transaction
If the passcode is invalid, you receive a 403 Forbidden status code with the following error:
Request example for verify TOTP Factor Response example for verify TOTP FactorVerify Push Factor
POST /api/v1/authn/factors/${factorId}/verify
CORS
Sends an asynchronous push notification (challenge) to the device for the user to approve or reject. The factorResult for the transaction has a result of WAITING, SUCCESS, REJECTED, or TIMEOUT.
Request parameters for verify Push FactorautoPush | user's decision to send a push to the device automatically | URL | Boolean | FALSE |
factorId | id of Factor | URL | String | TRUE |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
stateToken | state token for the current transaction | Body | String | TRUE |
Okta Verify Push details pertaining to auto-push
- You don't need to pass the autoPush flag to Okta unless you have a custom sign-in flow that doesn't use the Okta Sign-In Widget, but want Okta to keep track of this preference. The custom sign-in flow must still handle the logic to actually send the Auto-Push, since this param only deals with the Auto-Push setting.
- If you pass the autoPush query param when verifying an Okta Verify Push Factor, Okta saves this value as the user's preference to have the push notification sent automatically if the verification is successful (the user taps Approve on their phone).
- If there is already a saved Auto-Push preference, the successful verify call overrides the current preference if it is different from the value of autoPush.
- This saved Auto-Push preference is always returned in the /api/v1/authn/ response's autoPushEnabled field if the user is enrolled for the Okta Verify Push Factor example here. If the user's Auto-Push preference hasn't explicitly been set before, autoPushEnabled has a value of false.
- The Auto-Push preference is stored in a cookie value and users that clear their cookies remove that preference.
- Please note, the autoPush flag has no effect when trying to verify a Factor other than Okta Verify Push (factorId prefix = "opf").
Response example (waiting for 3-number verification challenge response)Note: Keep polling authentication transactions with WAITING result until the challenge completes or expires.
Response example (approved) Response example (rejected) Response example (timeout) Resend push notificationNote: If Okta detects an unusual sign-in attempt, the end user will receive a 3-number verification challenge and the correct answer of the challenge will be provided in the polling response. This is similar to the standard waiting response but with the addition of a correctAnswer property in the challenge object. The correctAnswer property will only be included in the response if the end user is on the 3-number verification challenge view in the Okta Verify mobile app. Look at Sign in to your org with Okta Verify (opens new window) for more details about this challenge flow.
Use the resend link to send another push notification if the user didn't receive the previous one due to timeout or error.
Request example for resend push notificationVerify Duo Factor
Verification of the Duo Factor is implemented as an integration with Duo widget. The process is very similar to the enrollment where the widget is embedded in an iframe - "duo_iframe". Verification starts with request to the Okta API, then continues with a Duo widget that handles the actual verification. We need to pass the state token as hidden object in "duo_form". The authentication completes with call to poll link to verify the state and obtain session token.
Request example for verify Duo Factor Response example for verify Duo Factor Sample for Duo iFrame Verification poll request example Verification poll response exampleVerify U2F fFactor
POST /api/v1/authn/factors/${factorId}/verify
CORS
Start verification to get challenge nonceNote: The appId property in Okta U2F enroll/verify API response is the origin (opens new window) of the web page that triggers the API request (assuming the origin has been configured to be trusted by Okta). According to FIDO spec (opens new window), enroll and verify U2F device with appIds in different DNS zone is not allowed. For example, if a user enrolled a U2F device via Okta Sign-in widget that is hosted at //login.company.com, while the user can verify the U2F Factor from //login.company.com, the user would not be able to verify it from Okta portal //company.okta.com, U2F device would return error code 4 - DEVICE_INELIGIBLE.
Verification of the U2F Factor starts with getting the challenge nonce and U2F token details and then using the client-side JavaScript API to get the signed assertion from the U2F token.
Request example for verify U2F Factor Response example for verify U2F Factor Get the signed assertion from the U2F token Post the signed assertion to Okta to complete verification Request parameters for verify U2F FactorclientData | base64-encoded client data from the U2F token | Body | String | TRUE |
factorId | id of Factor | URL | String | TRUE |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
signatureData | base64-encoded signature data from the U2F token | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Verify WebAuthn Factor
POST /api/v1/authn/factors/${factorIdOrFactorType}/verify
CORS
Verifies a user with a WebAuthn Factor. The verification process starts with getting the WebAuthn credential request options, which are used to help select an appropriate authenticator using the WebAuthn API. This authenticator then generates an assertion that may be used to verify the user.
Start verification to get challenge nonceNote: a factorId or factorType may be specified for WebAuthn's verify endpoint, as the WebAuthn Factor type supports multiple Factor instances. When a factorId is used, the verification procedure is no different from any other factors, with verification for a specific Factor instance. When "webauthn" (the factorType name for WebAuthn) is used, verification would be acceptable with any WebAuthn Factor instance enrolled for the user.
Verification of the WebAuthn Factor starts with getting the WebAuthn credential request details (including the challenge nonce) then using the client-side JavaScript API to get the signed assertion from the WebAuthn authenticator.
For more information about these credential request options, see the WebAuthn spec for PublicKeyCredentialRequestOptions (opens new window).
Request example for verify WebAuthn Factor Response example for verify WebAuthn Factor by factorId Response example for verify WebAuthn Factor by factorType Get the signed assertion from the WebAuthn authenticator Post the signed assertion to Okta to complete verification Request parameters for verify WebAuthn FactorauthenticatorData | base64-encoded authenticator data from the WebAuthn authenticator | Body | String | TRUE |
clientData | base64-encoded client data from the WebAuthn authenticator | Body | String | TRUE |
factorId | id of Factor | URL | String | TRUE (factorId OR factorType required) |
factorType | factorType of Factor; for WebAuthn, it is webauthn | URL | String | TRUE (factorId OR factorType required) |
rememberDevice | user's decision to remember the device | URL | Boolean | FALSE |
signatureData | base64-encoded signature data from the WebAuthn authenticator | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Recovery operations
Forgot password
POST /api/v1/authn/recovery/password
Starts a new password recovery transaction for a given user and issues a recovery token that can be used to reset a user's password
- Forgot Password with Email Factor
- Forgot Password with SMS Factor
- Forgot Password with Call Factor
- Forgot Password with Trusted Application
Request parameters for forgot passwordNote: Self-service password reset (forgot password) must be permitted via the user's assigned password policy to use this operation.
factorType | Recovery Factor to use for primary authentication | Body | EMAIL or SMS or CALL | FALSE | |
username | User's non-qualified short-name (for example: dade.murphy) or unique fully-qualified sign-in name (for example: ) | Body | String | TRUE |
Note: A valid factorType is required for requests without an API token with administrator privileges. For more information, see Forgot Password with Trusted Application.
Note: The optional parameter relayState can be included as part of the body in the Forgot Password request. relayState is a link to a site where the user will be redirected when the password recovery operation completes. The 'relayState' link must point to a trusted origin.
The response is different, depending on whether the request is for a public application or a trusted application.
Response parameters for public application for forgot passwordThe Recovery Transaction object with RECOVERY_CHALLENGE status for the new recovery transaction
You will always receive a Recovery Transaction response even if the requested username is not a valid identifier to prevent information disclosure.
Response parameters for trusted application for forgot passwordThe Recovery Transaction object with an issued recoveryToken that can be distributed to the end user
You will receive a 403 Forbidden status code if the username requested is not valid.
Forgot password with Email Factor
Starts a new password recovery transaction for the email Factor:
- You must specify a user identifier (username) but no password in the request.
- If the request is successful, Okta sends a recovery email asynchronously to the user's primary and secondary email address with a recovery token so the user can complete the transaction.
Primary authentication of a user's recovery credential (for example: EMAIL or SMS) hasn't completed when this request is sent. The user is pending validation.
Okta provides security in the following ways:
- Since the recovery email is distributed out-of-band and may be viewed on a different user agent or device, this operation does not return a state token and does not have a next link.
- Okta doesn't publish additional metadata about the user until primary authentication has successfully completed. See the Response Example in this section for details.
Forgot password with SMS Factor
Starts a new password recovery transaction with a user identifier (username) and asynchronously sends a SMS OTP (challenge) to the user's mobile phone. This operation will transition the recovery transaction to the RECOVERY_CHALLENGE state and wait for the user to verify the OTP.
Note: Primary authentication of a user's recovery credential (for example: email or SMS) hasn't yet completed. Okta doesn't publish additional metadata about the user until primary authentication has successfully completed.
Request example for forgot password with SMS Factor Response example for forgot password with SMS FactorNote: SMS recovery Factor must be enabled via the user's assigned password policy to use this operation.
Forgot password with Call Factor
Starts a new password recovery transaction with a user identifier (username) and asynchronously sends a Voice Call with OTP (challenge) to the user's phone. This operation transitions the recovery transaction to the RECOVERY_CHALLENGE state and wait for user to verify the OTP.
Notes:
- Primary authentication of a user's recovery credential (for example: email or SMS or Voice Call) hasn't yet completed.
- Okta won't publish additional metadata about the user until primary authentication has successfully completed.
- Voice Call recovery Factor must be enabled via the user's assigned password policy to use this operation.
Forgot password with trusted application
Allows a trusted application such as an external portal to implement its own primary authentication process and directly obtain a recovery token for a user given just the user's identifier
Note: Directly obtaining a recoveryToken is a highly privileged operation that requires an administrator API token and should be restricted to trusted web applications. Anyone that obtains a recoveryToken for a user and knows the answer to a user's recovery question can reset their password or unlock their account.
Request example for forgot password with trusted application Response example for forgot password with tusted applicationNote: The public IP address of your trusted application must be allowed as a gateway IP address to forward the user agent's original IP address with the X-Forwarded-For HTTP header.
Unlock account
POST /api/v1/authn/recovery/unlock
Starts a new unlock recovery transaction for a given user and issues a recovery token that can be used to unlock a user's account
- Unlock Account with Email Factor
- Unlock Account with SMS Factor
- Unlock Account with Trusted Application
Request parameters for unlock accountNote: Self-service unlock must be permitted via the user's assigned password policy to use this operation.
factorType | Recovery Factor to use for primary authentication | Body | EMAIL or SMS | FALSE | |
username | User's non-qualified short-name (for example: dade.murphy) or unique fully-qualified sign-in name (for example: ) | Body | String | TRUE |
Response parameter public application for unlock accountNote: A valid factorType is required for requests without an API token with administrator privileges. (See Unlock Account with Trusted Application).
Recovery Transaction object with RECOVERY_CHALLENGE status for the new recovery transaction
You always receive a Recovery Transaction response, even if the requested username isn't a valid identifier to prevent information disclosure.
Response parameter trusted application for unlock accountRecovery Transaction object with an issued recoveryToken that can be distributed to the end user
You receive a 403 Forbidden status code if the username requested is not valid.
Unlock account with Email Factor
Starts a new unlock recovery transaction with a user identifier (username) and asynchronously sends a recovery email to the user's primary and secondary email address with a recovery token that can be used to complete the transaction
Since the recovery email is distributed out-of-band and may be viewed on a different user agent or device, this operation does not return a state token and does not have a next link.
Notes:
- Primary authentication of a user's recovery credential (e.g EMAIL or SMS) hasn't yet completed.
- Okta will not publish additional metadata about the user until primary authentication has successfully completed.
Unlock account with SMS Factor
Starts a new unlock recovery transaction with a user identifier (username) and asynchronously sends an SMS OTP (challenge) to the user's mobile phone. This operation transitions the recovery transaction to the RECOVERY_CHALLENGE state and waits for the user to verify the OTP.
Notes:
- Primary authentication of a user's recovery credential (e.g email or SMS) hasn't yet completed.
- Okta won't publish additional metadata about the user until primary authentication has successfully completed.
- SMS recovery Factor must be enabled via the user's assigned password policy to use this operation.
Unlock account with trusted application
Allows a trusted application such as an external portal to implement its own primary authentication process and directly obtain a recovery token for a user given just the user's identifier
Notes:
Directly obtaining a recoveryToken is a highly privileged operation that requires an administrator API token and should be restricted to trusted web applications. Anyone that obtains a recoveryToken for a user and knows the answer to a user's recovery question can reset their password or unlock their account.
The public IP address of your trusted application must be allowed as a gateway IP address to forward the user agent's original IP address with the X-Forwarded-For HTTP header.
Verify recovery Factor
Verify SMS recovery Factor
POST /api/v1/authn/recovery/factors/sms/verify
Verifies a SMS OTP (passCode) sent to the user's mobile phone for primary authentication for a recovery transaction with RECOVERY_CHALLENGE status
Request parameters for verify SMS recovery FactorpassCode | OTP sent to device | Body | String | TRUE |
stateToken | state token for the current recovery transaction | Body | String | TRUE |
Recovery Transaction object with the current state for the recovery transaction
If the passCode is invalid, you receive a 403 Forbidden status code with the following error:
Request example for verify SMS recovery Factor Response example for verify SMS recovery Factor Resend SMS recovery challengePOST /api/v1/authn/recovery/factors/sms/resend
Resends a SMS OTP (passCode) to the user's mobile phone
Request parameters for resend SMS recovery challenge
stateToken | state token for the current recovery transaction | Body | String | TRUE |
Response parameters for resend SMS recovery challenge
Recovery Transaction object with the current state for the recovery transaction
Request example for resend SMS recovery challenge
Response example for resend SMS recovery challenge
Note: The factorType and recoveryType properties vary depending on recovery transaction.
Verify Call recovery Factor
POST /api/v1/authn/recovery/factors/call/verify
Verifies a Voice Call OTP (passCode) sent to the user's device for primary authentication for a recovery transaction with RECOVERY_CHALLENGE status
Request parameters for verify Call recovery FactorpassCode | Passcode received via the voice call | Body | String | TRUE |
stateToken | state token for the current recovery transaction | Body | String | TRUE |
Recovery Transaction object with the current state for the recovery transaction
If the passCode is invalid, you receive a 403 Forbidden status code with the following error:
Request example for verify Call recovery Factor Response example for verify Call recovery Factor Resend Call recovery challengePOST /api/v1/authn/recovery/factors/call/resend
Resends a Voice Call with OTP (passCode) to the user's phone
Request parameters for resend Call recovery challenge
stateToken | state token for the current recovery transaction | Body | String | TRUE |
Response parameters for resend Call recovery challenge
Recovery Transaction object with the current state for the recovery transaction
Request example for resend Call recovery challenge
Response example for resend Call recovery challenge
The factorType and recoveryType properties vary depending on the recovery transaction.
Verify recovery token
POST /api/v1/authn/recovery/token
Validates a recovery token that was distributed to the end user to continue the recovery transaction
Request parameters for verify recovery tokenrecoveryToken | Recovery token that was distributed to the end user via out-of-band mechanism such as email | Body | String | TRUE |
options | Opt-in features for the authentication transaction | Body | Options object | FALSE |
You can modify the authentication transaction state machine through the following opt-in features:
multiOptionalFactorEnroll | Transitions transaction back to MFA_ENROLL state after successful Factor enrollment when additional optional factors are available for enrollment | Boolean | TRUE | FALSE | FALSE |
Recovery Transaction object with a RECOVERY status and an issued stateToken that must be used to complete the recovery transaction
You receive a 401 Unauthorized status code if you attempt to use an expired or invalid recovery token.
Request example for verify recovery token Response example for verify recovery tokenAnswer recovery question
POST /api/v1/authn/recovery/answer
Answers the user's recovery question to ensure only the end user redeemed the recovery token for recovery transaction with a RECOVERY status
Request parameters for answer recovery questionanswer | answer to user's recovery question | Body | String | TRUE |
stateToken | state token for the current transaction | Body | String | TRUE |
Recovery Transaction object with the current state for the recovery transaction
You receive a 403 Forbidden status code if the answer to the user's recovery question is invalid.
Request example for answer recovery question Response example for answer recovery questionReset password
POST /api/v1/authn/credentials/reset_password
Resets a user's password to complete a recovery transaction with a PASSWORD_RESET state
This operation provides an option to revoke all the sessions of the specified user, except for the current session.
Request parameters for reset passwordnewPassword | User's new password | Body | String | TRUE | |
stateToken | state token for the current transaction | Body | String | TRUE | |
revokeSessions | When set to true, revokes all user sessions, except for the current session | Body | boolean | FALSE | FALSE |
Recovery Transaction object with the current state for the recovery transaction
You receive a 403 Forbidden status code if the answer to the user's recovery question is invalid.
You will also receive a 403 Forbidden status code if the newPassword does not meet password policy requirements for the user.
Request example for reset password Response example for reset passwordState management operations
Get transaction state
POST /api/v1/authn
Retrieves the current transaction state for a state token
Request parameters for get transaction statestateToken | state token for a transaction | Body | String | TRUE |
Transaction object with the current state for the authentication or recovery transaction
Request example for get transaction state Response example for get transaction statePrevious transaction state
POST /api/v1/authn/previous
Moves the current transaction state back to the previous state. For example, when changing state from the start of primary authentication to MFA_ENROLL > ENROLL_ACTIVATE > OTP, the user's phone might stop working. Since the user can't see the QR code, the transaction must return to MFA_ENROLL.
Request parameters for previous transaction statestateToken | state token for a transaction | Body | String | TRUE |
Transaction object with the current state for the authentication or recovery transaction
Request example for previous transaction state Response example for previous transaction stateSkip transaction state
POST /api/v1/authn/skip
Sends a skip link to skip the current transaction state and advance to the next state
If the response returns a skip link, then you can advance to the next state without completing the current state (such as changing the password). For example, after being warned that a password will soon expire, the user can skip the change password prompt by clicking a skip link.
Another example: a user has enrolled in multiple factors. After enrolling in one the user receives a skip link to skip the other factors.
Request parameters for skip transaction stateNote: This operation is only available for MFA_ENROLL or PASSWORD_WARN states when published as a link.
stateToken | state token for a transaction | Body | String | TRUE |
Transaction object with the current state for the authentication or recovery transaction
Request example for skip transaction state Response example for skip transaction stateCancel transaction
POST /api/v1/authn/cancel
Cancels the current transaction and revokes the state token
Request parameters for cancel transactionstateToken | state token for a transaction | Body | String | TRUE |
Transaction object
The Authentication API is a stateful API that implements a finite state machine with defined states and transitions. Each initial authentication or recovery request is issued a unique state token that must be passed with each subsequent request until the transaction is complete or canceled.
The Authentication API leverages the JSON HAL (opens new window) format to publish next and prev links for the current transaction state which should be used to transition the state machine.
Authentication transaction object
_embedded | embedded resources for the current status | JSON HAL (opens new window) | TRUE | TRUE | |
_links | link relations for the current status | JSON HAL (opens new window) | TRUE | TRUE | |
expiresAt | lifetime of the stateToken or sessionToken (See Tokens) | Date | TRUE | TRUE | |
factorResult | optional status of last verification attempt for a given Factor | Factor Result | TRUE | TRUE | |
sessionToken | ephemeral one-time token used to bootstrap an Okta session | String | TRUE | TRUE | |
stateToken | ephemeral token that encodes the current state of an authentication transaction | String | TRUE | TRUE | |
status | current state of the authentication transaction | Transaction State | FALSE | TRUE | |
type Early Access | type of authentication transaction. Currently available during step-up authentication | Authentication Type | TRUE | TRUE |
Recovery transaction object
_embedded | embedded resources for the current status | JSON HAL (opens new window) | TRUE | TRUE | |
_links | link relations for the current status | JSON HAL (opens new window) | TRUE | TRUE | |
expiresAt | lifetime of the stateToken or recoveryToken (See Tokens) | Date | TRUE | TRUE | |
factorResult | optional status of last verification attempt for the factorType | Factor Result | TRUE | TRUE | |
factorType | type of selected Factor for the recovery transaction | EMAIL or SMS | FALSE | TRUE | |
recoveryToken | ephemeral one-time token for recovery transaction to be distributed to the end user | String | TRUE | TRUE | |
recoveryType | type of recovery operation | PASSWORD or UNLOCK | FALSE | TRUE | |
stateToken | ephemeral token that encodes the current state of a recovery transaction | String | TRUE | TRUE | |
status | current state of the recovery transaction | Transaction State | FALSE | TRUE |
Transaction state
An authentication or recovery transaction has one of the following states:
LOCKED_OUT | The user account is locked; self-service unlock or administrator unlock is required. | POST to the unlock link relation to perform a self-service unlock. |
MFA_CHALLENGE | The user must verify the Factor-specific challenge. | POST to the verify link relation to verify the Factor. |
MFA_ENROLL_ACTIVATE | The user must activate the Factor to complete enrollment. | POST to the next link relation to activate the Factor. |
MFA_ENROLL | The user must select and enroll an available Factor for additional verification. | POST to the enroll link relation for a specific Factor to enroll the Factor. |
MFA_REQUIRED | The user must provide additional verification with a previously enrolled Factor. | POST to the verify link relation for a specific Factor to provide additional verification. |
PASSWORD_EXPIRED | The user's password was successfully validated but is expired. | POST to the next link relation to change the user's expired password. |
PASSWORD_RESET | The user successfully answered their recovery question and must to set a new password. | POST to the next link relation to reset the user's password. |
PASSWORD_WARN | The user's password was successfully validated but is about to expire and should be changed. | POST to the next link relation to change the user's password. |
RECOVERY_CHALLENGE | The user must verify the Factor-specific recovery challenge. | POST to the verify link relation to verify the recovery Factor. |
RECOVERY | The user has requested a recovery token to reset their password or unlock their account. | POST to the next link relation to answer the user's recovery question. |
SUCCESS | The transaction completed successfully. | |
UNAUTHENTICATED Early Access | User tried to access protected resource (for example: an app) but the user is not authenticated. | POST to the next link relation to authenticate user credentials. |
You advance the authentication or recovery transaction to the next state by posting a request with a valid state token to the the next link relation published in the JSON HAL links object for the response.
Enrolling a Factor and verifying a Factor do not have next link relationships as the end user must make a selection of which Factor to enroll or verify.
Note: Never assume a specific state transition or URL when navigating the state object. Always inspect the response for status and dynamically follow the published link relations.
Authentication type
Early Access
Represents the type of authentication. Currently available only during SP-initiated step-up authentication and IDP-initiated step-up authentication.
Tokens
Authentication API operations return different token types depending on the state of the authentication or recovery transaction.
State token
Ephemeral token that encodes the current state of an authentication or recovery transaction.
- The stateToken must be passed with every request except when verifying a recoveryToken that was distributed out-of-band
- The stateToken is only intended to be used between the web application performing end-user authentication and the Okta API. It should never be distributed to the end user via email or other out-of-band mechanisms.
- The lifetime of the stateToken uses a sliding scale expiration algorithm that extends with every request. Always inspect the expiresAt property for the transaction when making decisions based on lifetime.
Note: All Authentication API operations return 401 Unauthorized status codes when you attempt to use an expired state token.
Note: State transitions are strictly enforced for state tokens. You receive a 403 Forbidden status code if you call an Authentication API operation with a stateToken with an invalid state.
Recovery token
One-time token issued as recoveryToken response parameter when a recovery transaction transitions to the RECOVERY status.
- The token can be exchanged for a stateToken to recover a user's password or unlock their account.
- Unlike the statusToken the recoveryToken should be distributed out-of-band to a user such as via email.
- The lifetime of the recoveryToken is managed by the organization's security policy.
The recoveryToken is sent via an out-of-band channel to the end user's verified email address or SMS phone number and acts as primary authentication for the recovery transaction.
Note: Directly obtaining a recoveryToken is a highly privileged operation and should be restricted to trusted web applications. Anyone that obtains a recoveryToken for a user and knows the answer to a user's recovery question can reset their password or unlock their account.
Session token
One-time token issued as sessionToken response parameter when an authentication transaction completes with the SUCCESS status.
- The token can be exchanged for a session with the Session API or converted to a session cookie.
- The lifetime of the sessionToken is 5 minutes.
Factor result
The MFA_CHALLENGE or RECOVERY_CHALLENGE state can return an additional property factorResult that provides additional context for the last Factor verification attempt.
The following table shows the possible values for this property:
CANCELLED | Factor verification was canceled by user |
ERROR | Unexpected server error occurred verifying Factor. |
PASSCODE_REPLAYED | Factor was previously verified within the same time window. User must wait another time window and retry with a new verification. |
TIMEOUT | Unable to verify Factor within the allowed time window |
TIME_WINDOW_EXCEEDED | Factor was successfully verified but outside of the computed time window. Another verification is required in current time window. |
WAITING | Factor verification has started but not yet completed (e.g user hasn't answered phone call yet) |
Links object
Specifies link relations (see Web Linking (opens new window)) available for the current transaction state using the JSON (opens new window) specification. These links are used to transition the state machine of the authentication or recovery transaction.
The Links object is read-only.
next | Transitions the state machine to the next state Note: The name of the link relationship provides a hint of the next operation required |
prev | Transitions the state machine to the previous state |
cancel | Cancels the current transaction and revokes the state token |
skip | Skips over the current transaction state to the next valid state |
resend | Resends a challenge or OTP to a device |
Embedded resources
User object
A subset of user properties published in an authentication or recovery transaction after the user successfully completes primary authentication.
id | Unique key for user | String | FALSE | TRUE | TRUE |
passwordChanged | Timestamp when user's password last changed | Date | TRUE | FALSE | TRUE |
profile | User's profile | User Profile object | FALSE | FALSE | TRUE |
recovery_question | User's recovery question | Recovery Question object | TRUE | FALSE | TRUE |
User profile object
Subset of profile properties for a user
firstName | First name of user | String | FALSE | FALSE | TRUE | |
lastName | Last name of user | String | FALSE | FALSE | TRUE | |
locale | User's default location for purposes of localizing items such as currency, date time format, numerical representations, etc. | String | TRUE | FALSE | TRUE | RFC 5646 (opens new window) |
login | Unique login for user | String | FALSE | TRUE | TRUE | |
timeZone | User's time zone | String | TRUE | FALSE | TRUE | IANA Time Zone database format (opens new window) |
Remember device policy object
A subset of policy settings of the global session policy or an authentication policy published during MFA_REQUIRED, MFA_CHALLENGE states
allowRememberDevice | Indicates whether remember device is allowed based on the policy | Boolean | FALSE | FALSE | TRUE |
rememberDeviceByDefault | Indicates whether user previously opted to remember the current device | Boolean | FALSE | FALSE | TRUE |
rememberDeviceLifetimeInMinutes | Indicates how long the current verification would be valid (based on the policy) | Number | FALSE | FALSE | TRUE |
- rememberDeviceByDefault is true if the user has chosen to remember the current device.
- The value of rememberDeviceLifetimeInMinutes depends on the Factor lifetime value configured in the Sign-On Policy rule.
Recovery question object
User's recovery question used for verification of a recovery transaction
question | User's recovery question | String | FALSE | TRUE | TRUE |
Target object
Early Access
Represents the target resource that the user tried accessing. Typically this is the app that the user is trying to sign in to. Currently this is available only during SP-initiated step-up authentication and IDP-initiated step-up authentication.
_links | Discoverable resources for the target | JSON HAL (opens new window) | TRUE | FALSE | TRUE |
label | Label of the target resource | String | FALSE | FALSE | TRUE |
name | Name of the target resource | String | FALSE | FALSE | TRUE |
type | Type of the target resource. Currently only 'APP' is the supported type. | String | FALSE | TRUE | TRUE |
Authentication object
Early Access
Represents the authentication details that the target resource is using. Currently this is available only during SP-initiated step-up authentication and IDP-initiated step-up authentication.
issuer | The issuer of the assertion | Issuer object | FALSE | FALSE | TRUE |
protocol | The protocol of authentication | SAML2.0, SAML1.1 or WS-FED | FALSE | TRUE | TRUE |
Issuer object
The issuer that generates the assertion after the authentication finishes
id | Id of the issuer | String | TRUE | TRUE | TRUE |
name | Name of the issuer | String | FALSE | FALSE | TRUE |
uri | URI of the issuer | String | FALSE | FALSE | TRUE |
Password policy object
A subset of policy settings for the user's assigned password policy published during PASSWORD_WARN, PASSWORD_EXPIRED, or PASSWORD_RESET states
complexity | Password complexity settings | Password Complexity object | FALSE | FALSE | TRUE |
expiration | Password expiration settings | Password Expiration object | TRUE | FALSE | TRUE |
Password expiration object
Specifies the password age requirements of the assigned password policy
passwordExpireDays | number of days before the password is expired | Number | FALSE | FALSE | TRUE |
Password complexity object
Specifies the password complexity requirements of the assigned password policy
excludeUsername | Prevents username or domain from appearing in the password | Boolean | FALSE | FALSE | TRUE |
minLength | Minimum number of characters for the password | Number | FALSE | FALSE | TRUE |
minLowerCase | Minimum number of lowercase characters for the password | Number | FALSE | FALSE | TRUE |
minNumber | Minimum number of numeric characters for the password | Number | FALSE | FALSE | TRUE |
minSymbol | Minimum number of symbol characters for the password | Number | FALSE | FALSE | TRUE |
minUpperCase | Minimum number of uppercase characters for the password | Number | FALSE | FALSE | TRUE |
Note: Duplicate the minimum Active Directory (AD) requirements in these settings for AD-sourced users. No enforcement is triggered by Okta settings for AD-sourced users.
Password age object
Specifies the password requirements related to password age and history
historyCount | Number of previous passwords that the current password can't match | Number | FALSE | FALSE | TRUE |
minAgeMinutes | Minimum number of minutes required since the last password change | Number | FALSE | FALSE | TRUE |
Factor object
A subset of Factor properties published in an authentication transaction during MFA_ENROLL, MFA_REQUIRED, or MFA_CHALLENGE states
_embedded | embedded resources related to the Factor | JSON HAL (opens new window) | TRUE | FALSE | TRUE |
_links | discoverable resources for the Factor | JSON HAL (opens new window) | TRUE | FALSE | TRUE |
factorType | type of Factor | Factor Type | FALSE | TRUE | TRUE |
id | unique key for Factor | String | TRUE | TRUE | TRUE |
profile | profile of a supported Factor | Factor Profile object | TRUE | FALSE | TRUE |
provider | Factor provider | Provider Type | FALSE | TRUE | TRUE |
vendorName | Factor Vendor Name (Same as provider but for On-Prem MFA it depends on Administrator Settings) | Provider Type | FALSE | TRUE | TRUE |
Factor embedded resources
TOTP Factor activation objectTOTP factors, when activated, have an embedded verification object that describes the TOTP (opens new window) algorithm parameters.
_links | Discoverable resources related to the activation | JSON HAL (opens new window) | TRUE | FALSE | TRUE |
encoding | Encoding of sharedSecret | base32 or base64 | FALSE | FALSE | TRUE |
keyLength | Number of digits in a TOTP value | Number | FALSE | FALSE | TRUE |
sharedSecret | Unique secret key for prover | String | FALSE | FALSE | TRUE |
timeStep | Time-step size for TOTP | String | FALSE | FALSE | TRUE |
TOTP activation links objectNote: This object implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.
Specifies link relations (see Web Linking (opens new window)) available for the TOTP activation object using the JSON Hypertext Application Language (opens new window) specification. This object is used for dynamic discovery of related resources and operations.
qrcode | QR code that encodes the TOTP parameters that can be used for enrollment |
Describes previously enrolled phone numbers for the sms Factor
id | Unique key for phone | String | FALSE | TRUE | TRUE |
profile | Profile of phone | Phone Profile object | FALSE | FALSE | TRUE |
status | Status of phone | ACTIVE or INACTIVE | FALSE | FALSE | TRUE |
phoneNumber | Masked phone number | String | FALSE | FALSE | TRUE |
Push factors must complete activation on the device by scanning the QR code or visiting the activation link sent via email or SMS.
_links | Discoverable resources related to the activation | JSON HAL (opens new window) | FALSE | FALSE | TRUE |
expiresAt | Lifetime of activation | Date | FALSE | FALSE | TRUE |
Specifies link relations (see Web Linking (opens new window)) available for the push Factor activation object using the JSON Hypertext Application Language (opens new window) specification. This object is used for dynamic discovery of related resources and operations.
qrcode | QR code that encodes the push activation code needed for enrollment on the device |
send | Sends an activation link via email or sms for users who can't scan the QR code |
Specifies link relations (see Web Linking (opens new window)) available for the Factor using the JSON Hypertext Application Language (opens new window) specification. This object is used for dynamic discovery of related resources and operations.
The Factor Links object is read-only.
enroll | Enrolls a Factor |
questions | Lists all possible questions for the question Factor type |
resend | Resends a challenge or OTP to a device |
verify | Verifies a Factor |