Skip to content

HPC without User Context

This pattern uses Machine-to-Machine (M2M) authentication for automated HPC workflows where individual user identity is not required.

Overview

For automated pipelines, batch processing systems, or environments where a shared service account is acceptable, M2M authentication provides a simpler approach:

  • No user interaction required
  • Credentials managed centrally
  • Consistent identity across all jobs

When to Use This Pattern

  • Automated CI/CD pipelines running quantum benchmarks
  • Scheduled batch jobs that run without user intervention
  • Research workflows where individual attribution isn't required
  • Service accounts for shared team resources

Authentication Setup

Use the Machine-to-Machine (M2M) authentication flow.

Step 1: Obtain M2M Credentials

Contact your QLAM administrator to request M2M credentials:

  • Client ID - Identifies your application
  • Client Secret or Private Key - Authenticates your application

Step 2: Configure Credentials Securely

Store credentials using environment variables or a secret manager:

# In your environment or batch script
export QLAM_CLIENT_ID="your-client-id"
export QLAM_CLIENT_SECRET="your-client-secret"

Security

Never commit M2M credentials to source control. Use environment variables, secret managers (AWS Secrets Manager, HashiCorp Vault), or HPC-specific secret management.

Step 3: Authenticate in Your Application

Direct API approach:

#!/bin/bash
#SBATCH --job-name=quantum-batch

# Get access token
TOKEN=$(curl -s --request POST \
  --url "https://${AUTH_BASE_URL}/oauth/token" \
  --header "content-type: application/x-www-form-urlencoded" \
  --data grant_type=client_credentials \
  --data "client_id=${QLAM_CLIENT_ID}" \
  --data "client_secret=${QLAM_CLIENT_SECRET}" \
  --data "audience=${QLAM_AUDIENCE}" | jq -r '.access_token')

# Use token for API calls
curl -H "Authorization: Bearer ${TOKEN}" \
  "https://api.quera.com/v2/squin-256q/tasks"

Python approach:

import os
import time
import requests

_token_cache = {"token": None, "expires_at": 0}

def get_m2m_token():
    """Obtain M2M access token, returning a cached token if still valid."""
    if _token_cache["token"] and time.time() < _token_cache["expires_at"]:
        return _token_cache["token"]

    response = requests.post(
        f"https://{os.environ['AUTH_BASE_URL']}/oauth/token",
        data={
            "grant_type": "client_credentials",
            "client_id": os.environ["QLAM_CLIENT_ID"],
            "client_secret": os.environ["QLAM_CLIENT_SECRET"],
            "audience": os.environ["QLAM_AUDIENCE"],
        }
    )
    data = response.json()
    _token_cache["token"] = data["access_token"]
    # Refresh a bit early to avoid using an about-to-expire token
    expires_in = max(int(data["expires_in"]), 0)
    skew = min(60, expires_in)
    _token_cache["expires_at"] = time.time() + expires_in - skew
    return _token_cache["token"]

# Use in your application
token = get_m2m_token()
headers = {"Authorization": f"Bearer {token}"}

Cache Tokens Until Expiration

The identity provider enforces a monthly limit on M2M token requests. Always cache the access token and reuse it until it expires rather than requesting a new token for every API call. The example above demonstrates a simple in-memory cache; for multi-process environments (e.g. Slurm job arrays), consider writing the token and its expiration to a shared file or secret store so that all jobs can reuse it.

Using QLAM Packages

You can also use QLAM Shell or QLAM Core with M2M authentication. Both handle token caching automatically—see their M2M sections for configuration examples.

Workflow Example

┌─────────────────┐     ┌──────────────┐     ┌─────────────┐
│  Job Scheduler  │────▶│  Batch Job   │────▶│  QLAM API   │
│  (Slurm/PBS)    │     │              │     │             │
└─────────────────┘     └──────────────┘     └─────────────┘
                              │
                              │ M2M credentials
                              │ from environment
                              ▼
                        ┌──────────────┐
                        │   Identity   │
                        │   Provider   │
                        └──────────────┘

Benefits

  • No user interaction required
  • Simple credential management
  • Works in fully automated environments
  • No token refresh complexity (cache the token and request a new one when it expires)

Considerations

  • All API calls are attributed to the service account, not individual users
  • Requires secure credential storage infrastructure
  • May not meet audit requirements that need per-user attribution
  • Credentials must be rotated periodically for security

Comparison with User Context Pattern

Aspect M2M (This Pattern) User Context
User interaction None One-time login
Attribution Service account Individual user
Credential management Centralized Per-user
Audit trail Shared identity Per-user identity
Best for Automation Multi-user environments

Next Steps