Review: How Top CDN manage content authentication?

After reviewing the top CDN offerings, it seems that all of these follow more or less the same authentication approach to mitigate several problems, e,g, hotlinking, denial of services, etc.

I reviewed the following CDN providers.

- [Azure CDN](https://learn.microsoft.com/en-us/azure/cdn/cdn-token-auth)
- Cloudflare CDN
- [IBM CDN](https://cloud.ibm.com/docs/CDN?topic=CDN-working-with-token-authentication)
- [AWS Cloudfront](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/PrivateContent.html)

Usually, a CDN involves three actors:
1. CDN itself
2. A content Consumer
3. Client (an actor which is using the services of a CDN to serve content to consumers, e.g., A Web Application)

In Joystream network topology, I think there is not a clear distinction between these three actors. (It will be more clear after going over the authentication flow of an example provider)

>For most of the web applications/clients using the above-mentioned providers, before a consumer requests the protected content, they must get a token from the web application. The web application logic (for instance, username and password) validates the request. If the validation passes, it generates a one-time token and returns it to the client.

>When clients request the CDN contents, they must pass the token in a cookie, query string parameter, or request header. The request goes to the CDN Edge server, and the Edge server attempts to match it with the local token-auth setting. If the token is a verified match, the content is returned to the client. If the token doesn't match, the Edge server returns a 403 response.

### IBM CDN Authentication Flow

### Azure CDN Authentication Flow

### AWS Cloudfront Authentication Flow
On CloudFront, applications configure CloudFront to require that users access your files using either signed URLs or signed cookies. The application has to choose a public-private keypair and then 1) sign URL/cookies using a private pair, 2) give that signed message to an authenticated user, and 3) which the user/consumer will use in a CDN request for private content.

---
The above authentication flows gives a hint that before a consumer could interact with the CDN, a backend communication happens b/w CDN and web application/client, during which the client configures the CDN and generates some token, which is then passed to the consumer, who uses this token in a request for some asset to the CDN.

**However, in Joystream, the CDN (Argus) itself has to do the authentication, i.e., verifying infra access key, verifying persona, etc., at least for the first request; if we go without the lead node, and then it can issue a token just like client issues it in previous examples, which then can be reused in subsequent requests to the CDN.**

## Comments
- First and foremost, all these CDN providers require that viewers/consumers use `HTTPS` so that connections are encrypted when a CDN communicates with viewers, hence whatever scheme is used, token or signed message, the communication is safe from token reuse or replay attacks from the malicious actors.
- After studying all the providers, it seems to me that all the authentication schemes at most can help in limiting content access to only legitimate users; however, for parasitic users, you need `pay as you go` plan.
- Also, one more thing that is clear from looking at the CDN flows is that when serving the request for private content, CDN only verifies whether the request contains a valid token/request and that it, it does not concern itself with authentication & permissions stuff, whether the user has right credentials or whether it can view a specific asset (that's the domain of client/application)