Private vs Authenticated Assets in No-Code Flows

Pick the protection boundary first

Choose private delivery when the source file is the secret but its transformed derivatives may be public. Add strict transformations when only a controlled set of derivatives may be public. Choose authenticated delivery when the original and every derivative must require signed access.

A defined access window is a separate decision. First decide what must remain restricted: the source, selected derivatives, or every representation. Then apply the time rule to that boundary.

This distinction matters in media handling inside no-code application builders, where an upload action, transformation action, and delivery action may be separate blocks. Marking an upload private does not automatically make every later output private.

Cloudinary exposes the choice through the upload type parameter. Its upload-parameter reference, checked 26 August 2026, defines private as signed access to the original and authenticated as signed access to the original and all derived assets.

Condition	Private	Private with strict transformations	Authenticated	Pick
Only the original is secret	Original requires a signed URL; derivatives are public by default	Original requires a signed URL; only allowed or signed transformations can be created	Original and derivatives require signed access	Private
The original is secret and only approved derivatives may be public	Too permissive by default	Matches this boundary	More restrictive than required	Private with strict transformations
Every derivative is secret	Wrong boundary	Can restrict transformation creation, but does not express the rule as directly	Original and every derivative require signed access	Authenticated
Access is permitted only during a defined window	Needs a time-limited access mechanism in addition to the delivery type	Needs the same time rule plus transformation controls	Needs the time rule in addition to authenticated delivery	Choose the delivery type from the rows above, then add the window

Option 1: private delivery

A private asset is an asset whose original file cannot be delivered without a signed URL. Its derived versions are public by default.

That second sentence is the deciding fact. A resize, crop, format conversion, or other transformed result is a separate derived asset for delivery purposes. Private delivery protects the source boundary; it is not a promise that every representation of the content is restricted.

How it behaves

The no-code flow sets type to private when it uploads the asset. A request for the untransformed original needs a signed URL. A request for a transformed derivative does not require signed access by default.

This split is useful when the original contains something that should not be distributed directly but the delivery flow is supposed to publish derivatives. A source photograph could remain restricted while the flow delivers an approved resized or watermarked version publicly. The protection is attached to the original, not inherited as a blanket rule by everything derived from it.

What it costs

The flow needs a signing path whenever it delivers the original. That is an extra responsibility compared with a public upload, but public derivatives can still use ordinary delivery URLs.

The more important cost is review discipline. Whoever builds the flow must verify that every output intended for public delivery is safe to expose. If a derivative still contains the secret, private delivery has not protected it. The label can therefore create false confidence when a builder checks the upload block but not the transformation and delivery blocks.

There is no supplied benchmark for latency, engineering hours, or cost per request, so none should be inferred. The concrete operational obligation is narrower: sign original access and treat every default derivative as public.

When private is the wrong answer

Do not choose default private delivery when confidentiality follows the content rather than the source file. Cropping or resizing a confidential image does not make the information non-confidential. If every useful representation still contains the protected material, authenticated delivery expresses the required boundary.

Default private is also wrong when only particular derivatives are safe. If the policy says that one watermarked rendition may be public but arbitrary transformations may not be created, protecting only the original leaves too much transformation freedom. That case needs strict transformation controls.

Finally, private delivery alone does not express an access period. A signed URL to the original proves that the request carries a valid signature; a separate time-limited mechanism is needed when access must end at a defined time.

Option 2: private delivery with strict transformations

Private delivery plus strict transformations fits the middle case: the original is restricted, approved derivatives may be public, and unapproved transformation URLs must not create new derivatives.

Cloudinary’s media access-control documentation, checked 26 August 2026, says private originals require signed URLs while derived versions remain public by default. Enabling strict transformations blocks transformation URLs unless the transformation is explicitly allowed or the request is signed.

How it behaves

The private delivery type still protects the original. Strict transformation mode changes what can happen at the derivative boundary. The flow can:

• generate the required derivatives eagerly;
• mark specified transformations as allowed; or
• use signed URLs for transformations that are not otherwise allowed.

An allowed derivative may still be delivered publicly. Strict transformations govern which derivatives can be created; they do not turn every allowed derivative into an authenticated asset.

That distinction makes this option suitable when the secret is the source plus the ability to create arbitrary variants, but not the approved public output. The public output should be intentional rather than whatever transformation parameters a caller can place in a URL.

What it costs

The flow must define its transformation set rather than discovering new renditions casually at delivery time. That means maintaining at least one of three paths: eager generation, an allowlist, or signed transformation requests.

In a no-code system, the transformation names or parameters used by the delivery blocks must match that policy. Adding another crop, size, or format later is a policy change as well as a visual change. If the new transformation is neither generated, allowed, nor signed, delivery is blocked.

This pushes decisions earlier in the workflow. The team has to know which outputs it intends to publish and arrange for them to exist or be authorized. The companion choice between incoming and eager transformations becomes important because eager generation is one documented way to make required derivatives available under strict controls.

For a flow with a small, stable rendition set, that maintenance can be straightforward. For a builder that creates many user-selected variants, the allowlist or signing work grows with the transformation surface. No measured effort is supplied, so the cost should be described as added configuration and signing paths rather than a fabricated time estimate.

When strict-private is the wrong answer

Do not use this combination as a substitute for authenticated delivery when every derivative is confidential. Strict transformations can stop unapproved derivatives from being created, but approved derivatives may remain public. The question it answers is “which transformations may exist or be delivered,” not “must every request be authenticated.”

It is also the wrong fit when the product intentionally permits open-ended public transformation parameters. A strict allowlist conflicts with that requirement, while signing every novel transformation moves the flow toward a more controlled delivery architecture.

Use strict transformation allowlists for no-code delivery when the approved-derivative boundary is the actual requirement. Do not add strict mode merely because the word sounds more protective; add it when unapproved transformation creation is part of the threat being controlled.

Option 3: authenticated delivery

An authenticated asset requires signed access for the original and every derived asset. This is the direct choice when the content remains secret in all of its forms.

Cloudinary’s secure media delivery overview, checked 26 August 2026, places authenticated delivery at the fully restricted end of the delivery-type choice: both original and transformed versions require authorized access.

How it behaves

The flow uploads with type set to authenticated. An unsigned request for the original fails, and an unsigned request for a derived version also fails. There is no public-derivative exception comparable to default private delivery.

Authenticated delivery also changes transformation planning. Cloudinary’s current access-control documentation says authenticated assets cannot use on-the-fly transformations. Required derivatives must be generated ahead of time during upload or update using eager transformations. Each generated derivative has its own signature, returned by the upload or update response.

For a no-code flow, the practical sequence is therefore explicit:

1. Upload the asset as authenticated.
2. Request the required eager derivatives during upload or update.
3. Capture the returned signed delivery information.
4. Pass an authorized URL or access mechanism to the delivery step.

A block that merely constructs a transformation URL from a public ID is insufficient. The flow must preserve the authorization information associated with the original or chosen derivative.

What it costs

Every delivered representation crosses an authorization boundary. The flow cannot reserve signing logic for a rare original-download action while treating thumbnails and previews as ordinary public assets.

The lack of on-the-fly transformations is another concrete tradeoff. The required output set has to be generated ahead of delivery. If a later step asks for a derivative that was not prepared, the flow cannot create it merely by changing a URL at request time.

This adds work in three places: defining the eager transformation set, carrying the returned signed values between blocks, and ensuring that every consumer uses the authenticated delivery path. The supplied sources contain no measured latency or implementation-time comparison, so authenticated delivery should not be called slower or more expensive in general.

When authenticated is the wrong answer

Authenticated delivery is unnecessary when the product is intentionally publishing derivatives and only the source must remain restricted. Private delivery matches that condition with a smaller signing surface.

It is also a poor fit for a flow that needs arbitrary transformations chosen at the moment of viewing. Authenticated assets require derivatives to be prepared ahead of time, so the rendition set must be knowable during upload or update.

Do not choose authenticated merely because it sounds safer. Choose it when unsigned access to any derivative would violate the requirement. If public derivatives are part of the product, requiring signed access to all of them solves a problem the product does not have and adds authorization work to every delivery path.

A defined access window is a separate control

“Private or authenticated?” and “for how long?” are different questions.

The delivery type decides which representations require authorization. A time rule decides when otherwise valid access is permitted. The correct design can therefore be private plus a time-limited original link, strict-private plus a window, or authenticated plus a window.

For a private original, Cloudinary documents a time-limited signed download URL. Its private_download_url method accepts an expiration time and defaults to one hour when no expiry is supplied. The resulting request is handled through the authenticated API rather than cached on the CDN, and Cloudinary warns against embedding these links on a website because delivery consumes twice the bandwidth.

Cloudinary also documents asset access-control rules that can make an otherwise restricted asset public during a defined window. Outside that window, access is blocked unless another valid authorization method applies. The window therefore overlays the asset’s protection policy; it does not repair a delivery type whose source-versus-derivative boundary is wrong.

Use the dedicated time-limited media access in no-code workflows decision when expiry is the main requirement. The no-code flow must be able to issue or apply the timed access rule at the point where the user becomes entitled to the asset. Simply uploading as private or authenticated does not state when that entitlement ends.

Window examples

If a buyer may download the restricted original for a defined period while public previews remain available, choose private delivery and issue time-limited access to the original.

If an embargoed source has only approved public renditions after release, choose private with strict transformations and apply the publication window separately. Strict mode controls which derivatives exist; the window controls when access opens.

If a confidential file and every preview must be available only during an authorized session or period, choose authenticated delivery and add the relevant time-based access control. The time condition does not make private sufficient because the previews remain confidential.

Work the decision from the asset outward

A reliable no-code flow can make the decision in four passes.

1. Identify the secret

Ask whether the secret is the exact source file or the information carried by the file.

If the source must be withheld but a transformed publication copy is safe, start with private. If resizing, cropping, reformatting, or another transformation would still reveal the protected information, start with authenticated.

2. Decide whether arbitrary derivatives are acceptable

For private assets, derivatives are public by default. If any transformation may be requested and that is acceptable, default private matches the requirement.

If only named or prepared derivatives may be exposed, add strict transformations. Define the allowed or eager set before the delivery blocks depend on it.

If no derivative may be exposed without authorization, stop treating transformation control as the main boundary and choose authenticated.

3. Decide when access is valid

If access has no defined expiry, the delivery-type decision may be sufficient. If access should begin or end at a specified time, add an access-window mechanism. Do not encode the timing assumption only in a workflow delay or in the name of a link; the media access rule must carry the restriction.

4. Verify every output path

Test the original and at least one derivative separately. For private delivery, the expected result is a blocked unsigned original and a publicly accessible derivative unless strict controls intervene. For authenticated delivery, both unsigned requests should fail.

This check catches the most consequential configuration error: assuming the word private applies to derivatives when Cloudinary defines it around the original.

Which to pick when

Pick private delivery if the original source is the secret and transformed derivatives are intentionally public. The flow signs original access but can deliver derivatives publicly.

Pick private delivery with strict transformations if the original is secret and only a known set of derivatives may be public. Generate those derivatives eagerly, allow them explicitly, or sign requests outside the allowed set.

Pick authenticated delivery if every version carries the secret. Require signed access for the original and every derivative, and prepare the required transformations ahead of time.

Add time-limited access to whichever option matches the content boundary when the permission is valid only during a defined window. A window answers when access is allowed; private versus authenticated answers what must remain behind signed access.