How should I load images if I use token-based authentication

Question

I have a client-side application on domain client-domain.com and a server-side application on domain server-domain.com. There is an API on the serv

Answer 1

My solution to basically this exact same problem, based on Jeferson Tenorio's answer below (option 1), was to sign the URL to my API call with an encryption of the image and the user's JWT token, e.g. path/to/image?token=xxxx. In laravel this is easily accomplished with encrypt($your_object) and decrypt($token) (https://laravel.com/docs/5.7/encryption), and then I used the extracted token to verify the user had access to the file in question. But there are probably many other libraries capable of handling this.

I would be curious if there are any security concerns, but from my perspective the JWT is never exposed via plain text and the encryption relies on a secret key that malicious actors shouldn't have access to, so it seems like it should be fairly secure. My only real complaint is that the token is quite long using this method which does not make for presentable URLs.

Answer 2

There are three methods to solve it, the best approach to solve it is using the signed URLs

---

1. The first method simply creates a route without authentication (anonymous access) with a signature hash parameter that indicates if the resource can be loaded or not.

<img src="http://server-domain.com/path/to/image?guid=f6fc84c9f21c24907d6bee6eec38cabab5fa9a7be8c4a7827fe9e56f2">

When the server receives the request you must validate the guid if the expiration time not been reached and, of course, check if guid is a valid signature.

This approach is used by several files/documents servers like Dropbox, S3, CDN providers, etc.

See the technique in some companies.

• https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html#private-content-overview-choosing-duration

• https://client.cdn77.com/support/knowledgebase/cdn-resource/how-do-i-set-up-signed-urls

---

2. The second method is passed the token by querystring with the image URL.

   • This method is not recommendable because expose clearly the url and many servers sometimes write and expose public logs of URL accessed. The bad notice is that the JWT exposed normally the user can get control a lot of features further the image load.

<img src="http://server-domain.com/path/to/image?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c">

When the server receives the request you must validate the token by querystring and response with the content.

---

3. The third method creates an authenticated cookie to validate the access of the image.

   • This method is not recommendable because is out of API pattern (webapi/token based authentication in general).

When the server receives the request you need to validate if the validate cookie is valid.