Skip to content

Authentication & Credentials Isolation Guide

PowerMind InsightML enforces a strict security isolation model. Authentication credentials are split by operational scope, ensuring that external prediction clients cannot gain administrative or management access to datasets, experiments, or model configurations.

1. Authentication Modes

InsightML supports three authentication modes tailored to different users and scopes:

Auth Mode Authentication Header Intended Audience Operations Permitted
JWT Bearer Token Authorization: Bearer <jwt_token> Humans using the graphical web console. Create workspaces, projects, upload datasets, start AutoML experiments, deploy models, and manage API keys.
Platform API Key x-api-key: IML_live_platform_... CI/CD pipelines, automated training scripts, and developers using the Python SDK. Full programmatic access to all workspace and platform management endpoints (same scope as JWT).
Deployment API Key x-api-key: IML_live_deploy_... Production consumer applications, websites, or microservices making predictions. Inference only on one specific deployed model. Blocked from all platform management endpoints.

2. Security Segregation Architecture

To maintain a strong security boundary, the platform prevents credential reuse across scopes. This isolation is illustrated in the diagram below:

CREDENTIALS SEGREGATION & TRUST BOUNDARIES MANAGEMENT PLANE (JWT or Platform Key) Data Engineer / SDK Platform Services ⚙️ Create Workspace 📂 Upload Dataset ⚡ Run AutoML TRUST BOUNDARY INFERENCE PLANE (Deployment Key Only) Prediction Consumer Active Serving 🔮 Real-time Prediction 🚫 Platform APIs Blocked

Why is this separation necessary?

If your production client application is compromised, an attacker only gains access to prediction services for that single model version. They cannot delete projects, inspect training datasets, view other deployments, or run unauthorized AutoML experiments (which consume massive GPU/CPU resources).

3. Account Creation & JWT Authentication

Account Registration

Before interacting with the platform, you must register a user account.

  • Via Web Interface: Click Sign Up, fill in your email, username, and password.
  • Password Length: Passwords must be at least 12 characters long.
  • Default Workspace: When registration completes, the system automatically creates a default workspace named <username>-workspace for you.

Account Lockout Protection

To prevent brute-force attacks, the login endpoint enforces account lockouts:

  • Lockout Threshold: After 5 consecutive failed login attempts, the user account is locked.
  • Duration: The account remains locked for 15 minutes. Subsequent attempts will return an HTTP 403 Forbidden response.

Logging In

To retrieve an access token session via curl: 

curl -X POST https://your-instance.com/api/v1/auth/login \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "username=user@example.com&password=your_secure_password_123"
Response Payload: 
{
  "access_token": "eyJhbGciOiJIUzI1NiIsIn...",
  "token_type": "bearer",
  "expires_in": 900
}
On successful authentication, the server also returns a secure cookie named __Host-refresh_token containing a database-backed refresh token.

Token Refresh & Rotation

Access tokens expire after 15 minutes. To acquire a new access token without logging in again, request a refresh: 

curl -X POST https://your-instance.com/api/v1/auth/refresh
This endpoint automatically reads the __Host-refresh_token cookie, invalidates the old refresh token, and returns a new access token and rotated refresh token cookie.

Session Revocation (Logout)

Logging out revokes the session and clears the cookie: 

curl -X POST https://your-instance.com/api/v1/auth/logout

This access_token must be supplied in subsequent platform requests inside the header: Authorization: Bearer <access_token>.

4. Managing Platform API Keys

Platform API Keys replace JWT tokens for automation scripts, daemon processes, or Python SDK pipelines.

Generating a Platform API Key

  1. Log in to the web console.
  2. Switch to the Workspaces tab in the sidebar.
  3. Scroll down to the Platform API Keys section.
  4. Enter a descriptive name (e.g., github-actions-training-key) and click Generate.
  5. Copy the key immediately. The raw key starts with IML_live_ and will not be displayed again.

To generate a key via REST API: 

curl -X POST "https://your-instance.com/api-keys/?workspace_id=1&name=cli-automation" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN"

5. Managing Deployment API Keys

Deployment API Keys are restricted to online inference calls. They are tied to a specific deployment rather than the entire workspace.

Generating a Deployment Key

  1. Log in to the web console.
  2. Navigate to Projects and select your project.
  3. Scroll down to the Deployments panel.
  4. Select your running deployment.
  5. In the deployment details view, find Inference API Keys.
  6. Click Generate Key, input a name (e.g., production-app-client), and save the raw string.

To generate a deployment key via REST API: 

curl -X POST "https://your-instance.com/api/v1/deployments/5/api-keys" \
  -H "Authorization: Bearer YOUR_JWT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name": "marketing-app"}'

6. Access Control and Permissions Errors

If you pass a key into an endpoint that does not match its required scope, you will receive an error:

  • Error 401 Unauthorized (Missing authentication): No API key or Bearer token was provided in the headers, or the token is expired.
  • Error 401 Unauthorized (Invalid API key format): The key header exists but is missing the required IML_ signature prefix.
  • Error 403 Forbidden (This API key is restricted): A Deployment API key was used to request a management resource (e.g., trying to delete a workspace using an inference key).
  • Error 403 Forbidden (API key is not authorized for this deployment): A Deployment API key generated for Deployment A was sent to a prediction route serving Deployment B.