Retrieves second factor types available for the configured 2FA provider.

Pre authenticates an account by username and password. Returns different information depending on the 2FA configuration of the contact. Possible reasons of rejection with HTTP 200: PasscodeInvalid, ContactLocked or AccessDenied. Possible scenarios of pair (Status, Factor):

• Auth - Passcode - The user is eligible for secondary authentication. Authenticate endpoint must be called as the secondary step with passcode as input (obtained through mtan or 2FA application).
• Auth - Approve - The user is eligible for secondary authentication. Authenticate endpoint must be called as the secondary step.
• Auth - QrCode - The user is eligible for secondary authentication. Authenticate endpoint must be called as the secondary step.
• Allow - The user is configured to bypass secondary authentication or is authenticating from a trusted device. The session details are returned, and the user will be authenticated without a secondary step.

Performs secondary authentication using one of the available factors. The response depends on the chosen factor. If the two-factor authentication is disabled then the session details will be returned and the contact will be automatically authenticated. Possible reasons of rejection with HTTP 200: PasscodeInvalid, ContactLocked or AccessDenied. Possible scenarios of pair (Status, Factor):

• Allow - Passcode - The session details are returned and the user will be authenticated.
• Allow - Approve - The session details are returned and the user will be authenticated.
• Auth / NULL - Approve - The end-user will approve or reject the authentication request via a 2FA mobile app.
• Auth / NULL - QrCode - The end-user will scan the code received (as URL). For Auth status a temporary session is returned in order to allow status requests on the current authentication process. A callback is pending to be called by a 2FA provider to complete the authentication.

Checks the authentication status of an account by username and temporary session when async 2FA is enabled. This endpoint can return a response in two different ways:

• It can wait until the authentication session has been completed and return when the result is available.
• It can wait just for the next status update during the authentication session and return the new status. It can then be called once again to either retrieve the next status update or wait for the result to become available (depending on how it’s called this time). If the response is successful session details will be returned and the contact will be able to authenticate.

Authenticates an account through an id-server issued token containing information on contact’s external-id. If external-id provided is not unique, system input must be provided as well.

Authenticates a contact in an SSO scenario using an id-token received from id-server or an external identity provider. An access token will be generated for the contact associated with the external-id detailed in the id-token.

A contact calling this endpoint will log themselves off from the specific session they are in context of the call. An app calling this endpoint will log the contact off from all open sessions.

Unlocks a contact that was locked due to multiple failed authentication attempts (passcode or mTan). If the contact is not locked an HTTP 200 with Result = ContactAlreadyUnlocked will be returned.

Checks whether a contact is locked due to multiple failed authentication attempts (passcode or mTan) and retrieves his status.

Retrieves information on the ability of the contact to sign-in. This includes if the sign-in is enabled by the business, if the contact has locked themselves, their password and 2FA state, as well as their last login information. 2FA device information will be returned if 2FA provider supports device enrollment.

Changes the two-factor flag of a campaign contact in order to allow/disallow the second factor in an authentication process.

Changes the two-factor flag of a campaign contact in order to allow/disallow the second factor in an authentication process.

Updates contact second-factor settings for authentication. The contact needs to have sign-in enabled and password set.

This API is deprecated. Use POST /v1.0/contacts/{contactId}/sign-in/enable instead
Activates a contact directly. An activated contact can log in to a client facing app.

Enables contact sign-in ability to DFS.

This API is deprecated. Use POST /v1.0/contacts/sign-in/enable/{key} instead
Activates a contact using an activation key. If DFS is the identity provider, response will be populated with information relevant for the next steps following activation.

Enables contact sign-in ability through key validation which was sent to the contact. If DFS is the identity provider, response will be populated with information relevant for the next steps following activation.

This API is deprecated. Use POST /v1.0/contacts/{contactId}/sign-in/disable instead
Deactivates a contact. The contact will also be logged out of all open sessions and all their devices will be un-enrolled. A deactivated contact cannot log in to a client facing app.

Disables contact sign-in ability to DFS. The contact will also be logged out of all open sessions and all their devices will be un-enrolled.

This API is deprecated. Use POST /v1.0/contacts/{contactId}/sign-in/enable/send-key instead
Sends an email to a contact with a redirect URL and a generated key. This key may be used to activate the contact, as well as help set the first password. An activated contact can log in to a client facing app.

Sends an email or SMS to a contact with a redirect URL and a generated key. This key may be used to enable contact’s sign-in ability to DFS, as well as help set the first password. Caller may override default enable-sign-in redirect URL.

Unlocks a contact that was locked due to multiple failed authentication attempts (passcode or mTan). If the contact is not locked an HTTP 200 with Result = ContactAlreadyUnlocked will be returned.

Provides an API a Futurae server can call in order to deliver status updates as well as the result of a particular authentication attempt (also called authentication session). The URL will be called as a POST request with "Content-Type" header being "application/json". The body of the request will be a JSON object containing the following keys and corresponding values: user_id, username, session_id, result, status, status_msg and trusted_device_token. The session ID identifies the particular authentication session and is conditionally returned by /v1.1/authentication/authenticate endpoint.

Provides an API a Futurae server can call in order to inform the application when the enrollment was successfully completed. The body of the request will be a JSON object containing the following keys and corresponding values: user_id, username, activation_code and result. The value of the latter will always be "success", since the callback will only be called when the enrollment is completed successfully.

Returns the list of password policies with the details (including settings)

Updates contact password given the old password. The new password is validated against the contact password policies.

Triggers a forgotten password process based on username or email. The username takes the priority over email to identify the campaign contact if both are provided. If the contact is registered, then the details of the campaign contact are returned and an mTan is generated and sent to the contact.

Sends a forgotten password activation link by email to the given contactId provided that the contact exists, is active and for that the given mtan and sessionId are valid. After this call, the previous password, if existing, can no longer be used and the contact can log-in again only after setting a new password. If the system is in testing mode, due to testing reasons, the new generated activation key is returned. It can be used later in the reset password flow.

Sets a password for an existing, active contact which is not authenticated based on the provided activation key. Can be used for first password creation or for password reset as long as the contact is active already. If the activation key is valid, the new password is set for the contact. Once the password is set the contact should be redirected to a login page and use the new password. The new password is validated against the contact password policies. If it fails, the details about the validated polices are returned. The password-history policy is not relevant for this endpoint therefore is not executed.

Sets a new password for an existing, active contact with password set which is authenticated based on the contact id provided. The new password is validated against the contact password policies. If it fails, the details about the validated polices are returned.

Triggers a forgotten password flow based on username/email (username takes priority if both provided). In this first step, a key is sent to the mobile of the contact, and a session is generated and returned (to be validated together in the next step). The endpoint will return success even if it cannot find a contact, or the contact found is deactivated.

Sends a reset-password key to the email of the contact as a second step of the forgotten password flow, after preliminary-key and session are validated successfully. If a reset-password key is successfully sent to the contact, the current password can no longer be used. Caller may override default reset-password redirect URL.

Resets contact password through key validation which was sent to the contact. Key may be a reset-password key generated by the forgotten password flow or sent directly by the member, or it may be a first-time-password key generated when indirectly enabling contact sign-in ability. The new password is validated against the contact password policies, aside from password-history policy.

Sends a reset-password key. If a reset-password key is successfully sent to the contact, the current password can no longer be used. Caller may override default reset-password redirect URL.

Retrieves contact’s enrolled devices used for second factor authentication.

This API is used only in the context of an authenticated account (it requires a JWT token), when the account activates 2FA. If the enrollment is not required for the set factor, then the 2FA is enabled for that contact and it returns a Success response. If the enrollment is required for the set factor, then starts the enrollment of a user device using the specific two-factor which is set in the database. This is the first step of the enrollment process. If it is successful, then an ActivationQrCodeUrl is returned in the response. The end-user will scan the qr code using the mobile app (e.g. Futurae). If the enrollment is successful, then the 2FA provider will post the final result, the user identification and the activation code using the callback set in the database. The callback will post the request using api enrollment/complete.

Starts the enrollment process of an unauthenticated contact for the contact's device using the specific two-factor provider defined in the system settings. If this first step is successful (provided credentials are valid), and device enrollment is required (depending on the 2FA provider), then an ActivationQrCodeUrl is returned in the response. Then end-user is required to scan the verification QR code using the mobile app (e.g. Futurae). If the scan step is successful, then the 2FA provider will post the final result, the user identification and the activation code using a callback method configured for the provider. You may use this endpoint both if 2FA is disabled for the contact (successful process will enable it) or if 2FA is already enabled for the contact but no device is enrolled.