Since #241 we have cookie-based authentication. This solved the issue of opening images that require authentication. However, this approach only works for images on the same domain. If you'd visit example.com, where you'd login, and show a private image from atomicdata.dev, you would not be able to see it, because example.com's JS will not be able to set a cookie due to security.
So how do we deal with this?
We still want to have cross-domain authentication for automatically downloaded things
We can't set custom headers, because images requested automatically by the browser. Only the cookies for that domain are included
Set a cookie server-side
This is the de facto standard way of doing things. Servers control authentication and identies. We could add a /cookie endpoint, which returns a server-signed cookie (JWT) that proves to the server that the user is authenticated.
This approach is feasible, but it also feels like unnecessary complexity. Since the client owns the private key (and not the server), there is no need for the server to sign anything. It just adds another point of failure.
Add a query parameter with some token
Instead of requesting atomicdata.dev/myimage.png, you'd request atomicdata.dev/myimage.png?authResource=asdf. The client adds this token, which encodes an Authentication Resource (i.e. the same content as the cookie)
This means the client will need to add this query param to all image URLs.
Proxy all the images
Instead of requesting atomicdata.dev/myimage.png, we'd request example.com/proxy?url=atomicdata.dev/myimage.png. The proxy could then re-use the Authentication Resource created by the client, and gain access to the image.
This approach has a couple of downsides:
The proxy server can now access the image. This is not very privacy friendly.
It will be far slower because extra roundtrip, the image will load 2 to 3 times slower.
The proxy server will have far more work to do, which makes performance worse for other users.
Since #241 we have cookie-based authentication. This solved the issue of opening images that require authentication. However, this approach only works for images on the same domain. If you'd visit
example.com, where you'd login, and show a private image fromatomicdata.dev, you would not be able to see it, becauseexample.com's JS will not be able to set a cookie due to security.So how do we deal with this?
Set a cookie server-side
This is the de facto standard way of doing things. Servers control authentication and identies. We could add a
/cookieendpoint, which returns a server-signed cookie (JWT) that proves to the server that the user is authenticated.This approach is feasible, but it also feels like unnecessary complexity. Since the client owns the private key (and not the server), there is no need for the server to sign anything. It just adds another point of failure.
Add a query parameter with some token
Instead of requesting
atomicdata.dev/myimage.png, you'd requestatomicdata.dev/myimage.png?authResource=asdf. The client adds this token, which encodes an Authentication Resource (i.e. the same content as the cookie)This means the client will need to add this query param to all image URLs.
Proxy all the images
Instead of requesting
atomicdata.dev/myimage.png, we'd requestexample.com/proxy?url=atomicdata.dev/myimage.png. The proxy could then re-use the Authentication Resource created by the client, and gain access to the image.This approach has a couple of downsides: