Valet Key

## The problem it solves The **Valet Key** pattern solves a very specific scaling problem: how do you let a client transfer a large blob of data (a photo, a video, a backup file) to or from object storage without forcing every byte of that transfer through your application server? The name comes from the valet parking analogy: a valet key starts a car and lets it be driven a short distance, but can't open the trunk or glovebox, and the owner takes it back when done. The pattern gives clients an equivalent: a temporary, narrowly scoped credential that lets them talk directly to the storage service (Amazon S3, Azure Blob Storage, Google Cloud Storage, etc.) using the storage provider's own API, bypassing your compute tier entirely for the data-plane part of the operation. ## The two phases Mechanically, the flow has two phases. 1. **First**, the client asks your application server for permission to perform some storage operation, such as 'let me upload a file to path X' or 'let me download object Y.' Your server, which already holds long-lived credentials to the storage account (an IAM role, a storage account key, a service principal), performs whatever authorization checks it wants (is this user logged in, do they own this path, are they under quota) and then, instead of doing the transfer itself, cryptographically signs a URL. The server hands this signed URL back to the client. 2. **Second**, the client uses that URL directly against the storage service's REST endpoint. The storage service independently recomputes the HMAC over the incoming request and compares it to the signature embedded in the URL; if they match and the current time is within the stated validity window, the request is allowed, otherwise it is rejected with an authentication error. ## What the server signs On AWS this is a **pre-signed URL**; on Azure it's a **Shared Access Signature** (SAS) token; Google Cloud calls it a signed URL too. The signature is typically an **HMAC** computed, using the server's storage credentials as the signing key, over a canonical description of the intended request, namely: - the HTTP verb - the resource path - the query parameters - an expiration timestamp ## Why the pattern exists The reason this pattern exists is almost entirely about **offloading cost and bottlenecks** from the application tier. If every file upload or download streamed through your app servers: - you would pay compute and bandwidth for data your application logic never actually needs to touch; - your connection pools would be tied up for the duration of large transfers; - your app tier's horizontal scaling would need to track storage traffic rather than business logic traffic. Object storage services are built and priced to handle massive parallel throughput directly; letting clients talk to them natively means the data plane scales independently of, and usually far more cheaply than, the compute plane. ## The trade-off — control versus scale The core trade-off is control versus scale. Once you hand out a signed URL, you have delegated a specific, bounded slice of your storage credentials to code you do not control (the client). Two properties bound that delegation: - **Scope** — the URL is tied to one resource and one verb such as `PUT` to a single object key rather than a blanket grant to the whole bucket. - **Time** — the URL carries an expiration and stops validating shortly after issuance, usually minutes to a few hours. Both properties exist because the token is a **bearer credential**: whoever possesses the URL string can use it, with no additional login step, until it expires or the underlying signing key is rotated. That is the sharpest edge of the pattern: there is no username or password check on the second phase, only whether you possess this exact URL. ## Failure modes That bearer nature creates the pattern's characteristic failure modes. If a signed URL leaks, through browser history, a referrer header, a logging pipeline that captures full request URLs, or a misconfigured CDN cache, anyone who obtains it can exercise whatever scope and time window it was granted, with no further authentication. Because the URL is self-contained and validated purely by signature and clock, most implementations offer no way to revoke a single token early. You either: - wait for it to expire, or - rotate the account's signing key entirely, which kills every outstanding valid URL at once, not just the leaked one. ## Where it shows up A concrete real-world instance: - **Amazon S3 pre-signed URLs** are commonly used so a browser or mobile app can `PUT` a user-uploaded profile photo or video directly to a bucket, with the application server only handling the lightweight step of generating the URL after checking the user is authorized and under quota; the multi-megabyte file transfer itself never touches the app server's compute or network budget. - Similarly, **Azure Blob Storage SAS tokens** back video-ingestion pipelines in media platforms, where an ingestion service issues a short-lived, write-only SAS scoped to a single blob path per upload session, keeping the always-on ingestion service free of the actual video bytes.