Skip to main content

Access keys and authentication

Filebase uses the same authentication model as AWS S3: every API call is signed with an access key pair using AWS Signature Version 4 (SigV4). Any S3-compatible client signs requests automatically — you only need to supply the keys.

Access key pair

A pair consists of:

  • Access Key ID — public, identifies your account.
  • Secret Access Key — private, never sent over the wire (used to derive a per-request signature).

Both halves are required. View and rotate them in the Access Keys page of the console. See the Get started access keys page for the step-by-step.

How signing works

When you make an authenticated request:

  1. Your client builds the request (method, URL, headers, body).
  2. Your client computes a SHA-256 hash of the request (or UNSIGNED-PAYLOAD for streaming).
  3. Your client derives a signing key from the secret access key, the date, the region (auto), and the service (s3).
  4. Your client uses the signing key to HMAC-SHA-256 the canonical request.
  5. The resulting signature is sent in the Authorization header.

Filebase repeats steps 2–4 server-side and rejects the request if the signatures don't match.

You almost never need to think about this — the AWS CLI, AWS SDKs, rclone, s3cmd, Cyberduck, and every other S3 client handle signing for you.

Required values

SettingValueWhy
Endpointhttps://s3.filebase.ioFilebase S3 endpoint
RegionautoFilebase routes globally; no per-region buckets
Signature versions3v4 (SigV4)Only version Filebase accepts

Single key pair per account

Filebase issues one access key pair per account. We don't support per-key scoping or IAM-style policies today. If you need stricter separation between workloads, create separate Filebase accounts.

Keep secrets out of source control

A leaked secret access key gives an attacker full read-write access to every bucket on your account. Treat it like a password:

  • Store it in environment variables (FILEBASE_KEY, FILEBASE_SECRET) or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password CLI).
  • Never check it into git, even in .env files. Use .gitignore aggressively.
  • Rotate it immediately if you suspect exposure — see the Access Keys page in the console.

Granting limited access

When you need to give someone temporary, scoped access — letting a customer upload to one bucket, or a partner download a single file — use pre-signed URLs instead of sharing your access keys. A pre-signed URL embeds a short-lived signature for one specific operation on one specific object.

See pre-signed URLs for examples.

What's next