Internal users

Internal users can authenticate in one or more login authentication methods in an environment. This makes it possible to customise the sign-in experience for different application requirements.

Upload your users from a CSV file, with or without a password.

For an overview of user concepts such as internal users, external users, and external user stores, see the users overview.

User identifiers

Internal users support three user identifiers: email, phone number, and username. These identifiers form the credential, which is the username part when a user signs in with username and password.

You can enable one, two, or all three identifiers in the login authentication method. If more than one identifier is enabled, the user can sign in with any enabled identifier.

Only phone number as a user identifier.

Email, phone number, and username as user identifiers.

Password check

Internal users can authenticate with a password. The password is validated against the built-in password policy (default or policy group) and optionally an external password API.

Built-in password policy and aging

The default password policy is configured in the environment settings in the FoxIDs Control Client and applies when no password policy group is assigned to the user.

1. Select the Settings tab.
2. Select the Environment tab.
3. Find the Password settings section.
4. Configure the Default password policy box:
   • Password min length and Password max length define the allowed range.
   • Check password complexity enforces character class variety and ensures the password does not contain parts of the URL or user identifiers such as email, phone, or username.
   • Check password risk based on global password breaches rejects passwords found in risk lists. For self-hosted deployments, see risk passwords.
   • Banned characters (case-insensitive) blocks specific characters.
   • Password history (number of previous passwords, 0 to disable) prevents reuse of recent passwords.
   • Password max age in seconds (0 to disable) forces a change when a password becomes too old.
   • Soft password change in seconds (0 to disable) allows a grace period. During login, a non-compliant or expired password prompts the user to change it, but the user can still sign in until the grace period expires.
5. Click Update.

Password policy groups

You can define up to 10 password policy groups per environment. A group overrides the default password policy for the users it is assigned to.

1. Select the Settings tab.
2. Select the Environment tab.
3. Find the Password settings section.
4. Configure the Password policy groups box.
5. Click Add policy group and set the policy values, which are the same fields as the default policy, plus a name and an optional display name.
6. Click Update.

Apply a group to a user in Internal Users → edit the user → Advanced → Password policy, or set the password policy name when provisioning via the Control API. If no group is selected, the default environment policy is used.

External password API

You can optionally configure an external password API to validate passwords and/or notify about password changes.

If the built-in password policy rejects the password, the external password API is not called. The notification method on the external password API is only called if the password passes all configured policy checks.

Password or one-time password (passwordless)

The login authentication method is configured by default for user identifier plus password.

You can also enable one-time password (OTP) via email and/or SMS for passwordless sign-in, and you can create multiple login authentication methods with different combinations.

If both password and OTP are enabled, all enabled methods are offered. The UI can also allow self-service account creation.

If only OTP via email is enabled:

Create user

Depending on the selected login method configuration, users can create an account online.

The user chooses to create a new account on the login page.

This example shows the create-user form.

The page is composed of dynamic elements that can be customised per login method. In this example, the form contains Given name, Family name, Email, and Password fields. The Email field is the user identifier used for sign-in.

This is the configuration in the login method. In addition, the claim some_custom_claim is added to each user as a constant via a claim transform.

Provisioning

Internal users can be created, updated, and deleted in the Control Client or provisioned through the Control API. You can also upload many users from a CSV file.

Multi-factor authentication (MFA)

Two-factor and multi-factor authentication can be required per user. The user must then complete an additional factor and can register an authenticator app if it is not already registered.

Available factors are determined by the login authentication method and the user's data and settings. See two-factor and multi-factor authentication.

You can see whether an authenticator app is registered, and an administrator can deactivate it.

Password hash

Only a password hash is stored.

The hashing subsystem supports evolution. Hash metadata, which is the algorithm and parameters, is stored with each hash so old hashes can still be validated while new hashes use newer algorithms or parameters.

Currently supported hash algorithm P2HS512:10:

• HMAC (RFC 2104) with SHA-512 (FIPS 180-4)
• 10 iterations stored in the hash metadata, multiplied by 10,000 PBKDF2 rounds for a total of 100,000 iterations
• Salt length: 64 bytes
• Derived key length: 80 bytes
• Hash and salt are stored as Base64 URL encoded strings, which is Base64 without padding

Standard .NET libraries are used to compute the hash.