Use HMAC or encryption for deep links? On a few occasions I've converted URLs with authentication via a session cookie to deep link URL's with no cookie authentication. These are URL's with simple id's like /download/pdf/1. 

I convert them to deep links either by appending a HMAC of the ID (/download/pdf/1/7e3aefd25fb9…) or encrypting the ID using AEAD and omitting the id from the url (/download/pdf/7e3aefd25fb9…).

In both cases I store a longterm key on the server which is used for all deep links.

I was wondering: which (if any) of these approaches is best practice?


I like the HMAC approach because it clearly states the intent.
I like the AEAD approach because the programmer cannot read the ID from the url and then accidentally forget the authentication.


(I realize there is a third option which is to use an entirely random number for the deeplink. This is the simplest cryptographically speaking, and the best practice I suspect. But it has downsides because you must store these numbers and references to which resources they belong. Generating the URLs can't be done "on the spot" any more, you must push to the centralized storage.)

Usage scenarios:


The URL must work inside an iframe where cookies cannot be used in some browsers 
The URL is automatically opened by another application such as Androids PDF reader which has no access to your browser cookies
We send an email with the resource URL and the recipient has no account in the system 
We wants the users to be able to share the resource without sharing their credentials 


Description of the attacker:


he uses HTTP
he might have access to the website as a cookie-authenticated user but NOT to all resources
he might have some valid deep links in his possession
he can easily guess a valid ID
he should not be able to create a valid URL from an ID unless it was provided to him
he should not be able access the resource
In my opinion your choice should come down to whether you want to hide the ID or not. If not, the use of encryption is just extra complexity and not useful. Most AEAD schemes allow decryption without authentication if the programmer really tries, so even that benefit is not very convincing to me.

A MAC, on the other hand, fits the problem perfectly well.

(Of course HTTP and plaintext email mean that your system has holes. Especially the former, since any eavesdropper to the connection will get to know both the URL and the content if you do not use TLS.)