Qiniu Cloud · Authentication Profile

Qiniu Authentication

Authentication

Qiniu Cloud secures its APIs with apiKey and hmac-signature across 3 declared security schemes, as derived from its OpenAPI definitions.

CompanyCloudObject StorageCDNMedia ProcessingLive StreamingIAMSDKAIChina
Methods: apiKey, hmac-signature Schemes: 3 OAuth flows: API key in: header

Security Schemes

Qiniu hmac-signature
QBox hmac-signature
UploadToken token

Source

Authentication Profile

qiniu-authentication.yml Raw ↑
generated: '2026-07-20'
method: searched
source: https://developer.qiniu.com/kodo/1201/access-token
docs: https://developer.qiniu.com/kodo/1201/access-token
summary:
  types: [apiKey, hmac-signature]
  credential: AccessKey / SecretKey (AK/SK)
  credential_source: https://portal.qiniu.com (console -> key management)
  api_key_in: [header]
schemes:
  - name: Qiniu
    type: hmac-signature
    algorithm: HMAC-SHA1
    header: 'Authorization: Qiniu <AccessKey>:<EncodedSign>'
    description: >-
      Management/access token. Signs the HTTP method, path, query, host, selected
      headers and body with the SecretKey, URL-safe-base64 encodes it, and
      concatenates it with the AccessKey. Used for resource-management operations
      (delete/move/copy, bucket admin, IAM). Invalid signatures return HTTP 401.
    encoding: url-safe base64
  - name: QBox
    type: hmac-signature
    algorithm: HMAC-SHA1
    header: 'Authorization: QBox <AccessKey>:<EncodedSign>'
    description: >-
      Legacy management token variant signing path + query + body. Still accepted
      by many management endpoints; the newer Qiniu signature is recommended.
  - name: UploadToken
    type: token
    description: >-
      Scoped, expiring token minted client-side from AK/SK for a specific bucket
      (and optional key/policy). Presented on upload requests to the up.* hosts.
      Carries a PutPolicy (scope, deadline, callback, returnBody, mimeLimit, etc.).
    header: 'Authorization: UpToken <token> (or multipart token field)'
notes: >-
  Qiniu has no OAuth2/OIDC surface — there is no scope reference and no
  /.well-known discovery. All authentication derives from the account AK/SK pair;
  IAM sub-accounts get their own AK/SK keypairs with policy-based permissions.