Private Customer Documents: Portal Sign-In or an Expiring Download Link?

Choose the access rule before deciding how to email a customer a document. A portal can require the recipient to sign in and pass a permission check. A temporary download link can deliberately grant access to whoever possesses that link. Those are different promises, even if both arrive in the same email.

This guide concerns downloading a private document that already exists, not accepting uploads or opening a mobile app from a shared link. The practical choice is how much identity checking and ongoing control the document needs, and how much friction the recipient can reasonably manage.

Does possession of the link suffice?

Start with the business question: would it be acceptable if the intended recipient forwarded the link to somebody else? If not, do not describe a bearer link as recipient-only access. An authenticated portal with appropriate document permissions is a different option to discuss. Signing in alone is not enough; the app must also decide whether that account may read that document.

Amazon S3's presigned URL documentation provides a concrete example of the other model. It describes presigned URLs as bearer tokens that grant access to those who possess them, within the permissions of the creator. A signed URL is therefore an intentional temporary access grant, not proof of the downloader's identity.

For a document whose forwarding risk is acceptable, that convenience may be useful. For sensitive or account-specific material, ask whether a signed-in route better matches the requirement. This is a design decision for your circumstances, not a claim that either approach makes every document secure.

Expiring does not mean one use

AWS states that an S3 presigned URL can be used multiple times until it expires. If your brief says “one-time download,” an ordinary presigned URL does not by itself deliver that rule. A separate mechanism and its limits would need to be specified and demonstrated.

Also distinguish the email link from the final storage URL. An email may lead to a portal page that checks permission and only then issues a short-lived download URL. In that arrangement, ask what happens to a storage URL already issued if the person's portal permission is later removed. Do not assume changing the portal account automatically cancels every previously issued grant.

Ask the developer to explain both layers in plain language. Avoid public or staff instructions promising instant withdrawal unless the actual method supports it and has been tested.

What happens at the expiry boundary?

S3 checks expiry when an HTTP request starts. AWS explains that a download started before expiry can continue afterwards, while restarting a dropped download after expiry fails. Expiry is not a promise to interrupt every transfer at an exact second.

The nominal duration is not the only limit either. AWS says a link created using temporary credentials expires when those credentials expire, even if a later expiry was requested. Keep that product fact scoped to S3; other storage services need their own documentation review.

Specify the customer experience for an expired link: a clear explanation and a legitimate way to request access again. If access has been withdrawn, that path must not issue a new link without checking the current permission. Do not fix confusion by making links valid indefinitely or by giving the signing service broader permissions.

A downloaded file is another copy

As practical guidance, distinguish blocking a future request from retrieving a file somebody already downloaded. Do not promise remote deletion of ordinary downloaded copies. Explain any relevant handling expectations separately, without claiming that an expiry setting controls the recipient's device.

Treat the URL itself as sensitive access material. Do not paste real signed customer links into analytics, support screenshots, shared task descriptions or demonstration documents. Use invented files and authorized test accounts when discussing or testing the feature. Record access events without unnecessarily copying usable grants into logs.

An acceptance test that exposes the difference

Ask for an isolated demonstration with a harmless test document. Check an authorized portal user, a user without permission, a valid temporary link, repeated use before expiry and a request after expiry. If withdrawal is promised, test an already-issued link after access changes and record what actually happens.

Where large downloads matter, include a started transfer and a later retry around the expiry boundary. Write down what was tested rather than infer a result from the chosen duration. Make renewal behaviour and the remaining forwarding risk visible in the handover.

Bring the document type, recipient needs and withdrawal expectations to a customer-portal project discussion. The right deliverable is a clearly bounded access model with demonstrated behaviour, not a vague promise of a “secure link.”