Basic authentication is a generic backend integration mechanism that allows users to log in to {product-title} with credentials validated against a remote identity provider.
Because basic authentication is generic, you can use this identity provider for advanced authentication configurations.
|
Caution
|
Basic authentication must use an HTTPS connection to the remote server to prevent potential snooping of the user ID and password and man-in-the-middle attacks. |
With basic authentication configured, users send their user name and password to {product-title}, which then validates those credentials against a remote server by making a server-to-server request, passing the credentials as a basic authentication header. This requires users to send their credentials to {product-title} during login.
|
Note
|
This only works for user name/password login mechanisms, and {product-title} must be able to make network requests to the remote authentication server. |
User names and passwords are validated against a remote URL that is protected by basic authentication and returns JSON.
A 401 response indicates failed authentication.
A non-200 status, or the presence of a non-empty "error" key, indicates an
error:
{"error":"Error message"}
A 200 status with a sub (subject) key indicates success:
{"sub":"userid"} (1)
-
The subject must be unique to the authenticated user and must not be able to be modified.
A successful response can optionally provide additional data, such as:
-
A display name using the
namekey. For example:{"sub":"userid", "name": "User Name", ...} -
An email address using the
emailkey. For example:{"sub":"userid", "email":"[email protected]", ...} -
A preferred user name using the
preferred_usernamekey. This is useful when the unique, unchangeable subject is a database key or UID, and a more human-readable name exists. This is used as a hint when provisioning the {product-title} user for the authenticated identity. For example:{"sub":"014fbff9a07c", "preferred_username":"bob", ...}