Presigned URLs: Temporary Access to Private Files

WHY IT EXISTS: Applications often need to grant temporary access to private files in cloud storage without creating permanent user credentials or proxying large files through their own servers, which is inefficient and costly.

THE MENTAL MODEL: Think of a presigned URL as a time-sensitive, single-use keycard. Instead of giving a user a master key (your API credentials) to your entire storage bucket, you generate a temporary keycard that only works for one specific door (a single file) for a specific action (like opening it to read) and expires after a few minutes.

HOW IT WORKS: Your backend server, which has permanent credentials to the cloud storage service, generates the presigned URL. It uses its secret key to create a cryptographic signature that includes the bucket name, object key, the allowed HTTP method (e.g., GET for download, PUT for upload), and an expiration timestamp. This signature is appended to the object's URL as a query parameter. When a client uses this URL, the cloud provider validates the signature and checks the expiration time before granting access.

WHEN TO USE IT: The primary use case is client-side uploads and downloads. For example, when a user wants to upload a profile picture, your server generates a presigned PUT URL and sends it to the browser. The browser can then upload the image file directly to that URL, bypassing your server. This also works for serving user-specific generated content, like a private financial report.

WHEN NOT TO USE IT: Do not use presigned URLs for public content; just make the object public instead. Avoid using them for long-term access; they are meant to be short-lived. If you need complex, multi-file access control, a more robust authentication system like OAuth 2.0 might be a better fit.

ONE CANONICAL EXAMPLE: A user clicks "Download my invoice". Your web server authenticates the user, then asks your cloud storage provider to generate a presigned URL for the specific invoice PDF in a private bucket. The server sets the expiration to 5 minutes and redirects the user's browser to this long, signed URL. The browser downloads the file directly from cloud storage, which validates the signature before serving the file. Your server never has to handle the file stream.