Crusoe · Authentication Profile
Crusoe Authentication
Authentication
Crusoe secures its APIs with http and apiKey across 3 declared security schemes, as derived from its OpenAPI definitions.
ai-infrastructurecloud-computinggpu-computemachine-learninginferencekubernetesobject-storageinfrastructure-as-a-serviceenergymcp
Methods: http, apiKey
Schemes: 3
OAuth flows:
API key in: header
Security Schemes
CrusoeSignedRequest http
scheme: bearer
· in: header ()
InferenceApiKey http
scheme: bearer
· in: header ()
ObjectStorageKey apiKey
· in: header ()
Source
Authentication Profile
generated: '2026-08-04'
method: searched
source: https://docs.crusoecloud.com/reference/api/
docs:
- https://docs.crusoecloud.com/reference/api/
- https://docs.crusoecloud.com/identity-and-security/managing-api-keys
note: >-
The published Swagger 2.0 documents at api.cloud.crusoe.ai/v1/openapi.json and /v1alpha5/openapi.json
declare NO securityDefinitions and NO security requirements, even though every operation returns a
401 "Error Authentication Failed" response. The auth model below is therefore taken from the docs,
not derived from the spec. This is a real contract gap: an agent or generated client reading the spec
alone cannot authenticate. See conformance/crusoe-conformance.yml.
summary:
types: [http, apiKey]
api_key_in: [header]
oauth2_flows: []
declared_in_openapi: false
schemes:
- name: CrusoeSignedRequest
api: Crusoe Cloud API Gateway
type: http
scheme: bearer
in: header
header: Authorization
format: 'Bearer <version:access_key_id:base64_encoded_signature>'
companion_headers:
- name: X-Crusoe-Timestamp
format: RFC 3339 timestamp
purpose: replay-attack prevention
signature:
version: '1.0'
algorithm: HMAC-SHA256
key: raw-urlsafe-base64-decoded secret key
encoding: base64
payload_fields:
- http_path
- canonicalized_query_params
- http_verb
- timestamp_header_value
payload_separator: newline
canonical_query_params: >-
Parameters sorted lexicographically by name and joined with "&"; when there are no query
parameters the canonical string is a single newline.
credentials:
kind: access key ID + secret key pair
issued_at: https://console.crusoecloud.com/security/cloud-api-keys
secret_visibility: shown once at creation only
expiration: optional, set at creation
revocation: permanent delete from the console Security page
sources:
- https://docs.crusoecloud.com/reference/api/
- name: InferenceApiKey
api: Crusoe Managed Inference API
type: http
scheme: bearer
in: header
header: Authorization
format: 'Bearer <inference_api_key>'
note: >-
OpenAI-compatible endpoint at api.inference.crusoecloud.com; a plain bearer API key, not the signed
request used by the API Gateway. Unauthenticated requests to ANY path on this host, including
/.well-known/*, return HTTP 401 {"errors":["Authentication failed"]}.
credentials:
kind: API key
issued_at: https://console.crusoecloud.com/security/inference-api-keys
secret_visibility: shown once at creation only
expiration: optional, set at creation
sources:
- https://docs.crusoecloud.com/serverless-inference
- https://docs.crusoecloud.com/identity-and-security/managing-api-keys
- name: ObjectStorageKey
api: Crusoe Cloud Object Storage (S3-compatible)
type: apiKey
in: header
note: >-
Object Storage issues its own S3-style access keys, managed through the S3Keys endpoints of the API
Gateway (createS3Key / listS3Keys / deleteS3Key) and documented separately.
docs: https://docs.crusoecloud.com/storage/object-storage/managing-storage-api-keys
authorization:
model: project-scoped RBAC
note: >-
Almost every API Gateway operation is scoped by a project_id path parameter (175 of 232 operations),
and IAM role bindings assign roles to users within an organization. There is no OAuth 2.0 scope
surface, so no scopes/ artifact is emitted.
operations:
- listRoles
- listRoleBindings
- applyRoleBindings
enterprise_identity:
sso:
supported: true
providers: [Okta]
note: organization-wide SSO enforcement is currently Okta-only
operations: [createSSOProvider, listSSOProviders, deleteSSOProvider, updateUserSSOEnforcement]
scim:
supported: true
note: SCIM integration endpoints are published on the API Gateway for user provisioning
mfa:
supported: true
social_login:
providers: [Google, GitHub]
scope: console sign-in only, not organization SSO enforcement
source: https://docs.crusoecloud.com/resources/changelog
x-evidence:
fetched: '2026-08-04'
urls:
- https://docs.crusoecloud.com/reference/api/
- https://docs.crusoecloud.com/identity-and-security/managing-api-keys
- https://api.cloud.crusoe.ai/v1/openapi.json
http_status: 200