Fermyon Authentication

generated: '2026-09-09'
method: searched
source: openapi/fermyon-accounts-api-openapi.yml, openapi/fermyon-apps-api-openapi.yml, openapi/fermyon-auth-tokens-api-openapi.yml,
  openapi/fermyon-channels-api-openapi.yml, openapi/fermyon-custom-domains-api-openapi.yml, openapi/fermyon-device-codes-api-openapi.yml,
  openapi/fermyon-key-value-pairs-api-openapi.yml, openapi/fermyon-key-value-stores-api-openapi.yml, openapi/fermyon-oci-api-openapi.yml,
  openapi/fermyon-payments-api-openapi.yml, openapi/fermyon-personal-access-tokens-api-openapi.yml, openapi/fermyon-revisions-api-openapi.yml
  ...
summary:
  types:
  - apiKey
  api_key_in:
  - header
schemes:
- name: Bearer
  type: apiKey
  in: header
  parameter: Authorization
  description: 'JWT Authorization header using the Bearer scheme. Example: "Authorization: Bearer {token}"'
  sources:
  - openapi/fermyon-accounts-api-openapi.yml
  - openapi/fermyon-apps-api-openapi.yml
  - openapi/fermyon-auth-tokens-api-openapi.yml
  - openapi/fermyon-channels-api-openapi.yml
  - openapi/fermyon-custom-domains-api-openapi.yml
  - openapi/fermyon-device-codes-api-openapi.yml
  - openapi/fermyon-key-value-pairs-api-openapi.yml
  - openapi/fermyon-key-value-stores-api-openapi.yml
  - openapi/fermyon-oci-api-openapi.yml
  - openapi/fermyon-payments-api-openapi.yml
  - openapi/fermyon-personal-access-tokens-api-openapi.yml
  - openapi/fermyon-revisions-api-openapi.yml
  - openapi/fermyon-sql-databases-api-openapi.yml
  - openapi/fermyon-variable-pairs-api-openapi.yml
docs:
- https://developer.fermyon.com/cloud/user-settings
- https://developer.fermyon.com/cloud/cloud-command-reference
- https://techdocs.akamai.com/akamai-functions/docs/manage-accounts
note: 'Upgraded from derived to searched on 2026-09-09 against the Fermyon Cloud documentation. The single
  Bearer scheme below is the whole story: a JWT in the Authorization header on all 61 operations, no scopes,
  no oauth2 securityScheme, and no OpenID metadata. Token acquisition is not in the securityScheme but
  is fully specified by the contract, so it is recorded here.'
token_acquisition:
- method: personal-access-token
  operations:
  - POST /api/personal-access-tokens
  - GET /api/personal-access-tokens
  - DELETE /api/personal-access-tokens/{id}
  note: The token value is returned once, in PersonalAccessTokenValue. Listing returns only id, name and
    createdAt.
- method: device-code
  operations:
  - POST /api/device-codes
  - GET /api/device-codes/{userCode}
  - POST /api/device-codes/activate
  note: What `spin cloud login` drives. DeviceCodeItem returns deviceCode, userCode, verificationUrl,
    expiresIn and interval — the RFC 8628 device authorization response fields, camelCased — but the endpoints
    and token exchange are not RFC 8628. See conformance/fermyon-conformance.yml.
- method: token-exchange-and-refresh
  operations:
  - POST /api/auth-tokens
  - POST /api/auth-tokens/refresh
  note: Returns TokenInfo {token, refreshToken, expiration}.
authorization:
  scopes: []
  rbac: false
  evidence: 'No scopes are declared anywhere in the contract and no permission or role entity exists in
    any schema. The Akamai Functions documentation states it outright: "Akamai Functions does not support
    Role-Based Access Control (RBAC). Everyone has the same level of permissions and any member can permanently
    delete any application in the account." (https://techdocs.akamai.com/akamai-functions/docs/manage-accounts)'
  agent_impact: A token cannot be scoped down. Any token an agent holds can delete every application in
    the account.
credential_storage:
  cli: As of `spin aka` v0.7.0 (2026-03-20) plugin login credentials are stored in the operating system
    native secret store — macOS Keychain, Linux secret service, Windows Credential Manager — rather than
    a plain-text config file. Existing credentials migrate automatically. (https://techdocs.akamai.com/akamai-functions/changelog/mar-20-2026-spin-aka-v070-updates)