Authentication
To use Engine you need an account. Get in touch at info@cloudomation.com to request a trial account. When you sign up you create a workspace with one user. You can later add more users to your workspace. All users of your workspace will share the same resources in Engine.
Below are the descriptions on how to authenticate with Engine using different methods.
Engine users are locked out when there are too many failed login attempts. When a user is locked out Engine sends an email to the user with instructions to recover the account.
Engine will send emails to users to inform them about security-relevant changes to their account. This includes:
- account activation
- change of email address
- change of password
- enable/disable 2FA
- account locked-out
- account recovery
Via the User Interface
To authenticate via the user interface you need to visit your workspace's login page. Your login page is accessible under https://<your-workspace-name>.cloudomation.com. You need to enter your user name and your password. If you enabled two-factor authentication for your user you also have to enter the current 2FA code.
Once all the required fields are filled in, you can click on "Login". If the authentication is successful your browser receives a cookie. The cookie contains a JWT token which is used to authenticate by subsequent requests. The validity period of this cookie is 30 days by default. This period can be configured using the Workspace Configuration. Please refer to Security for configuration options.
Engine supports LDAP integration. See more here.
Via the REST API
To authenticate using the REST API you need to POST a JSON string containing your credentials to https://<your-workspace-name>.cloudomation.com/api/latest/auth/login. An example JSON might look like:
{
"user_name": "kevin",
"password": "secret"
"authentication_method": "cloudomation"
}
authentication_method can be either "cloudomation" (if the user is defined in Engine) or "ldap:<ldap_config_name>" (if you want to use LDAP integration).
If successful, the API will respond with HTTP 302 and a Set-Cookie header.
If unsuccessful, the API returns with HTTP 401: Unauthorized
Via an API key (browser session)
An API key (created on a user's detail page, under API keys (MCP / programmatic access)) authenticates REST and MCP requests directly — send it as an Authorization: Bearer cldm_<prefix>_<secret> header (or in the x-cloudomation-api-key header). This is the recommended credential for agents and automation.
An API key alone is also enough to drive the authenticated web UI. The single-page app and its websocket state-channel authenticate with the same session_id cookie that a username/password login sets, so an API-key holder can obtain that cookie without a separate password by POSTing to:
https://<your-workspace-name>.cloudomation.com/api/latest/auth/session-from-key
with the API key supplied in the Authorization: Bearer … (or x-cloudomation-api-key) header. No request body is required.
If successful, the API responds with HTTP 302 and a Set-Cookie header setting session_id; point a browser (or headless browser) at the workspace with that cookie and the authenticated UI loads. If the key is missing, invalid, or belongs to a disabled user, the API returns HTTP 401: Unauthorized.
The browser session is bound to the same user identity as the API key, so it carries exactly that identity's roles and scope — it grants no additional access. The session uses the standard login-session lifetime (LOGIN_TOKEN_VALIDITY_HOURS, independent of the API key's own expiry) and can be revoked like any login session (log out, or clear the user's session). Because the endpoint requires the API key in a request header — which browsers do not send cross-site — it is not exposed to CSRF.