Prompt and context
This system-design question tests the lifecycle and authorization boundary of temporary credentials. The challenge is not wrapping object-storage signing APIs; it is keeping a link narrowly capable and controllable through leakage, revocation, key rotation, and multi-region access.
What the interviewer evaluates
- Whether a signed URL is bound to tenant, object, method, version, range, and expiry.
- Whether signing, live authorization, revocation, and storage permissions are distinguished.
- Whether key rotation, short caching, CDN delivery, rate limits, and audit flow are designed.
- Whether leakage, replay, clock skew, regional failure, and revocation delay trade-offs are explained.
Clarifying questions to ask
Confirm download versus upload, single object versus batch, Range and multipart needs, maximum lifetime, seconds-level revocation, and CDN involvement. Ask about tenant isolation, audit retention, key management, multi-region recovery, and object-version semantics.
30-second answer framework
An authorization service first validates the caller, then signs a URL bound to tenant, object version, operation, conditions, and a short expiry. The signature covers a normalized request and key version; storage or the edge verifies it. High-risk revocation uses short TTLs, a deny-list, or a version-revoked marker. The URL grants only necessary capabilities, while immutable audit events, replay detection, rate limits, and key rotation contain risk.
Step-by-step deep dive
1. Define the credential and permission model
Include tenant, an object key or unguessable id, version, allowed method, byte range, content-type constraints, issuer, expiry, and key version. An upload URL also limits size, checksum, and destination prefix. The server performs live object authorization before signing; clients cannot edit parameters to enlarge permission.
2. Choose signing and verification paths
Use a storage-compatible HMAC or asymmetric signature that covers method, path, query parameters, important headers, and expiry. Canonicalize whitespace, encoding, and parameter ordering. The verifier checks the time window, key version, signature, and conditions. Sensitive operations still use live checks instead of putting every authorization decision into a self-contained URL.
3. Design revocation, rotation, and replay defenses
Short expiry limits the impact of leakage. For high-value links, Redis or edge rules can hold a token id, object-version revocation, or tenant deny-list. During key rotation, keep the old version until the longest URL lifetime ends, then remove it. One-time uploads can require a nonce, object state, and completion marker; repeated downloads follow an explicit business policy.
4. Scale storage, CDN, and failures
Keep issuance stateless, with metadata and revocation in highly available storage. Send object bytes directly through storage or a CDN instead of the application server. CDN policy must include signature and permission boundaries so one tenant’s private response cannot be reused by another. If key management or revocation storage is unavailable, fail closed for new issuance and high-risk access; treat already-issued low-risk links according to their documented TTL.
5. Observe, rate-limit, and verify security
Audit issuer, tenant, object, method, result, region, a client-fingerprint summary, and revocation reason without logging the full URL query. Limit issuance rate, total bytes, and concurrency by tenant, user, object, and IP; detect anomalous reuse. Test parameter tampering, expiry, clock skew, rotation, revocation delay, cross-tenant access, CDN hits, and regional failure.
Strong sample answer
After validating the caller, the authorization service issues a URL bound to tenant, immutable object version, method, conditions, and short expiry. The signature covers the canonical path, query, and critical headers; storage or CDN verifies it, so the app does not proxy large files. High-risk links support revocation through short TTLs, a deny-list, or version markers. Retain old keys until the longest link expires. Audit issuance and access results without full URLs, rate-limit by tenant and object, and test tampering, replay, skew, rotation, revocation, cross-tenant access, and CDN isolation.
Common mistakes
- Signing only an object path without tenant, method, version, or upload conditions.
- Treating a permanent URL as a revocation mechanism and having no leakage containment.
- Deleting an old key immediately during rotation and breaking valid links.
- Caching private content by path alone at the CDN and ignoring signatures or tenants.
- Writing full signed URLs to logs, analytics, or error messages.
- Testing signature validity only and skipping tampering, replay, clock skew, and revocation delay.
Follow-up questions and answers
Why not put all authorization in a JWT?
A signed URL binds conditions to a resource request that storage can verify without proxying large bytes, but it is not a real-time revocation system. High-risk privileges still need short TTLs, version revocation, or live checks.
How can revocation take effect within seconds?
Have the edge or verifier check a high-priority deny-list, object-version marker, or tenant state with a very short cache TTL. This increases reads and consistency pressure, so apply it by risk tier.
How does an upload URL prevent overwriting another object?
Bind it to an immutable key or one-time upload id, If-None-Match, size, and checksum. On completion, recheck tenant and object state and reject path replacement or duplicate completion.
Should a CDN cache signed URLs?
It can cache bytes only when the key, headers, and TTL prevent private responses from crossing permission boundaries. High-risk or very short-lived resources can bypass shared cache, trading hit rate for isolation and controllable revocation.