Which of the following answers describe the features of totp? (select 3 answers)

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

1. 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.

2. For more advanced use cases, learn the Okta API basics.

3. 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.

Options object

The authentication transaction state machine can be modified via the following opt-in features:

Context object

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.

Note: 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).

Device Token best practices

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 failures

If 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 password

User must change their expired password to complete the authentication transaction.

Note: Users are challenged for MFA (MFA_REQUIRED) before PASSWORD_EXPIRED if they have an active Factor enrollment.

Response example for primary authentication with public application (Factor challenge)

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.

Request example for trusted application

Response example for trusted application

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.

Request example for activation token

Response example for activation token (success - user with password, no MFA)

Response example for activation token (success - user with password and configured MFA)

Response example for activation token (success - user without password)

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.

Note: 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.

Device fingerprint best practices

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.

Request example for device fingerprinting

Response example for device fingerprinting

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.

Request example for password expiration warning

Response example for password expiration warning

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 https://login.example.com, then Okta will redirect to https://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.

Note: Global session policy and the related authentication policy are evaluated after successful primary authentication.

Response example for step-up authentication without Okta session when MFA isn't required

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 session

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.

Note: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.

Response example for Factor challenge for step-up authentication with Okta session

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 session

Note: 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.

Note: Okta Sign-on Policy and the related App Sign-on Policy are evaluated after successful primary authentication.

Request example for IDP-initiated step-up authentication

Note: audience is a Deprecated parameter.

Response example when MFA isn't required

Note: Sign in to the app by following the next link relation.

Response example for Factor enroll

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.

Note: In Identity Engine, the MFA Enrollment Policy name has changed to authenticator enrollment policy.

Response example for Factor challenge

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 application

Change 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

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 password

Multifactor 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

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

Note: The Security Question Factor doesn't require activation and is ACTIVE after enrollment.

Request example for enroll Okta Security Question Factor

Response example for enroll Okta Security Question Factor

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 enrollment

Use the resend link to send another OTP if the user doesn't receive the original activation SMS 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.

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 enrollment

Use the resend link to send another OTP if the user doesn't receive the original activation Voice Call 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.

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 enrollment

Use the resend link to send another OTP if user doesn't receive the original activation email OTP.

Enroll 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.

Note: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.

Request example for enroll Okta Verify TOTP Factor

Response example for enroll Okta Verify TOTP Factor

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.

Note: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.

Request example for enroll Okta Verify Push Factor

Response example for enroll Okta Verify Push Factor

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 factor

Enroll 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 Factor

Enroll 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 Factor

Enroll 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 Factor

Enroll 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 Factor

Full page example for Duo enrollment

In this example we put all of the elements together in the html page.

Activation poll request example

Verifies successful authentication and obtains a session token

Activation poll response example

Enroll 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.

Note: 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 https://login.company.com, while the user can verify the U2F Factor from https://login.company.com, the user would not be able to verify it from Okta portal https://company.okta.com. The U2F device would return error code 4 - DEVICE_INELIGIBLE.

Enroll U2F request example

Enroll U2F response example

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 parameters

Enroll WebAuthn response parameters

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).

Note: 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 WebAuthn request example

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

Note: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.

Request parameters for activate TOTP Factor

Response parameters for activate TOTP Factor

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 example

Activate 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 parameters

Activate SMS Factor response parameters

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 example

Activate 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 parameters

Activate Call Factor response parameters

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 example

Activate 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 parameters

Activate Email Factor response parameters

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 example

Activate 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 parameters

Activate Push Factor response parameters

Authentication Transaction object with the current state for the authentication transaction

Activate Push Factor request example

Activate Push Factor response example (waiting)

Note: Follow the the published next link to keep polling for activation completion.

Activate Push Factor response example (success)

Activate Push Factor response example (timeout)

Note: Follow the the published activate link to restart the activation process.

Poll for Push Factor activation

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.

Send activation links

Sends 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.

Note: 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 method

Activate a u2f Factor by verifying the registration data and client data.

Activate U2F request parameters

Activate U2F response parameters

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 example

Activate 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 library

Activate a webauthn Factor by verifying the attestation and client data.

Activate WebAuthn request parameters

Activate WebAuthn response parameters

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 example

Verify 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 Factor

Response parameters for verify Security Question Factor

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 Factor

Verify SMS Factor

POST /api/v1/authn/factors/${factorId}/verify

CORS

Request parameters for verify SMS Factor

Note: If you omit passCode in the request, a new OTP is sent to the device, otherwise the request attempts to verify the passCode.

Response parameters for verify SMS Factor

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.

Resend SMS challenge

Use the resend link to send another OTP if the user doesn't receive the original SMS 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.

Verify SMS challenge (OTP)

Specify passCode in the request to verify the Factor.

Verify Call Factor

POST /api/v1/authn/factors/${factorId}/verify

CORS

Request parameters for verify Call Factor

Note: If you omit passCode in the request, a new OTP is sent to the device, otherwise the request attempts to verify the passCode.

Response parameters for verify Call Factor

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.

Resend voice call challenge

Use the resend link to send another OTP if the user doesn't receive the original Voice Call 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.

Verify Call challenge (OTP)

Specify passCode in the request to verify the Factor.

Verify TOTP Factor

POST /api/v1/authn/factors/${factorId}/verify

CORS

Verifies an OTP for a token:software:totp or token:hotp Factor

Note: This API implements the TOTP standard (opens new window), which is used by apps like Okta Verify and Google Authenticator.

Request parameters for verify TOTP Factor

Response parameters for verify TOTP Factor

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:

Verify 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 Factor

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").

Request example for verify Push Factor

Response example (waiting)

Note: Keep polling authentication transactions with WAITING result until the challenge completes or expires.

Response example (waiting for 3-number verification challenge response)

Note: 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.

Response example (approved)

Response example (rejected)

Response example (timeout)

Resend push notification

Use the resend link to send another push notification if the user didn't receive the previous one due to timeout or error.

Verify 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 example

Verify U2F fFactor

POST /api/v1/authn/factors/${factorId}/verify

CORS

Note: 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 https://login.company.com, while the user can verify the U2F Factor from https://login.company.com, the user would not be able to verify it from Okta portal https://company.okta.com, U2F device would return error code 4 - DEVICE_INELIGIBLE.

Start verification to get challenge nonce

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 Factor

Request example for signed assertion

Response of U2F verification example

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.

Note: 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.

Start verification to get challenge nonce

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 Factor

Request example for signed assertion

Response of WebAuthn verification example

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

Note: Self-service password reset (forgot password) must be permitted via the user's assigned password policy to use this operation.

Request parameters for forgot password

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 password

The 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 password

The 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.

Request example for forgot password with Email Factor

Response example for forgot password with Email Factor

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.

Note: SMS recovery Factor must be enabled via the user's assigned password policy to use this operation.

Request example for forgot password with SMS Factor

Response example for forgot password with SMS Factor

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.

Request example for forgot password with Call Factor

Response example for forgot password with Call Factor

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.

Note: 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.

Request example for forgot password with trusted application

Response example for forgot password with tusted application

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

Note: Self-service unlock must be permitted via the user's assigned password policy to use this operation.

Request parameters for unlock account

Note: A valid factorType is required for requests without an API token with administrator privileges. (See Unlock Account with Trusted Application).

Response parameter public application for unlock account

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 account

Recovery 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.

Request example for Email Factor

Response example for Email Factor

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.

Request example for unlock account with SMS Factor

Response example for unlock account with SMS Factor

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.

Request example for unlock account with SMS Factor (trusted application)

Response example for unlock account with SMS Factor (trusted application)

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 Factor

Response parameters for verify SMS recovery Factor

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

POST /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

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 Factor

Response parameters for verify Call recovery Factor

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

POST /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

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 token

Options object

You can modify the authentication transaction state machine through the following opt-in features:

Response parameters for verify recovery token

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 token

Answer 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 question

Response parameters for answer recovery question

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 question

Reset 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 password

Response parameters for reset password

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 password

State management operations

Get transaction state

POST /api/v1/authn

Retrieves the current transaction state for a state token

Request parameters for get transaction state

Response parameters for get transaction state

Transaction object with the current state for the authentication or recovery transaction

Request example for get transaction state

Response example for get transaction state

Previous 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 state

Response parameters for previous transaction state

Transaction object with the current state for the authentication or recovery transaction

Request example for previous transaction state

Response example for previous transaction state

Skip 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.

Note: This operation is only available for MFA_ENROLL or PASSWORD_WARN states when published as a link.

Request parameters for skip transaction state

Response parameters for skip transaction state

Transaction object with the current state for the authentication or recovery transaction

Request example for skip transaction state

Response example for skip transaction state

Cancel transaction

POST /api/v1/authn/cancel

Cancels the current transaction and revokes the state token

Request parameters for cancel transaction

Request example for cancel transaction

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

Recovery transaction object

Transaction state

An authentication or recovery transaction has one of the following states:

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:

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.

Embedded resources

User object

A subset of user properties published in an authentication or recovery transaction after the user successfully completes primary authentication.

User profile object

Subset of profile properties for a user

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

When sign-on policy is device based

When sign-on policy is time based

• 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.

When policy is not based on time or device

Recovery question object

User's recovery question used for verification of a recovery transaction

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.

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 object

The issuer that generates the assertion after the authentication finishes

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

Password expiration object

Specifies the password age requirements of the assigned password policy

Password complexity object

Specifies the password complexity requirements of the assigned password policy

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

Factor object

A subset of Factor properties published in an authentication transaction during MFA_ENROLL, MFA_REQUIRED, or MFA_CHALLENGE states

Factor embedded resources

TOTP Factor activation object

TOTP factors, when activated, have an embedded verification object that describes the TOTP (opens new window) algorithm parameters.

Note: 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.

Phone object

Describes previously enrolled phone numbers for the sms Factor

Push Factor activation object

Push factors must complete activation on the device by scanning the QR code or visiting the activation link sent via email or SMS.

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.

Factor links object

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.

Which of the following terms describes the process of tracking authorized and unauthorized usage of a resource or use of rights by a subject?

Which are examples of biometric security measures choose all that apply?

How does fingerprint authentication work?

What term is used for a means of authentication based on what the users have?