Logo

Security & Privacy Whitepaper (Overview)Chapter 4

Chapter 4 Authentication, Authorization & Access Control

This chapter defines FileBolt's identity model, token layers, and access control boundaries. Upload and download use short-lived access tokens (server-side sessions, lookup-based, expiring, scoped) to gate ciphertext and manifest access. Sender management actions use long-lived login tokens stored on the client. The system MUST support revocation, and audit data MUST be visible only to the sender.

4.0 Summary

  • Short-lived access token: gates ciphertext/manifest access; server-side session (lookup); MUST bind to transferId; MUST be scoped; MUST expire.
  • Long-lived login token: used for sender management (delete/revoke/audit); stored on the client; MUST NOT be used by recipients to access ciphertext.
  • Separation of keys and authorization: tokens control ciphertext access only; decryption capability comes from CEK in the URL fragment (see Chapter 5).

4.1 Identity model

  • The system supports a paid-user identity model for sender management.
  • Sender login MAY use a one-time magic link; the client stores a long-lived login token after successful authentication.
  • Recipients are not required to have an account for default downloads (see UX docs); access is link/token controlled.

4.2 Authorization model & token layers

Two token types are used with strict separation of responsibility:

  1. Short-lived access token (session / lookup): for upload/download of ciphertext and manifest read; MUST bind to transferId; MUST expire; MUST be scoped by operation.
  2. Long-lived login token: for sender management actions; MUST NOT grant decryption capability.

4.2.2 Scope examples

  • upload_chunk: upload ciphertext chunk(s) for a specific transferId.
  • read_manifest: read manifest for a specific transferId.
  • download_chunk: download ciphertext chunk(s) for a specific transferId.

4.3 Upload authorization

  • Upload APIs MUST validate token scope and transferId binding before accepting ciphertext.
  • Chunk uploads SHOULD be idempotent per (transferId, fileId, chunkIndex).
  • On invalid token or mismatch, the system MUST fail closed.

4.4 Download authorization

  • Manifest and ciphertext access MUST require a valid, scoped token; tokens MUST be time-limited.
  • Recipients MUST NOT be able to enumerate other transfers or access chunks outside the bound transferId.
  • Rate limiting MAY be applied for abuse prevention (see Chapter 7) without breaking resumability.

4.5 Revocation & early invalidation

  • Senders MUST be able to revoke a transfer; revocation MUST make tokens unusable for subsequent access.
  • Revocation SHOULD trigger cleanup/TTL acceleration for ciphertext where feasible.
  • Recipient UX MUST clearly indicate revoked/expired status and the next step (contact sender).

4.6 Audit & permission isolation

  • Delivery evidence (downloads, counts) MUST be visible to the sender only by default.
  • Audit APIs MUST require sender authentication and MUST be isolated from recipient access tokens.

4.7 Logging & sensitive-data minimization

  • Logs MUST NOT contain URL fragments, CEK, or derivable key material.
  • Logs SHOULD minimize personal data and focus on security-relevant events (token failures, revocation, rate limits).
  • Error messages MUST be actionable but must not leak secrets.

4.8 Related Claim IDs