URL token validation: Add more parameters like user_id and URL to token?


#1

Hi everyone,

We have to restrict access to some content to specific users and found this helpful tutorial:

https://docs.fastly.com/guides/tutorials/enabling-url-token-validation.html

If we understand correctly the URL with the token could be passed to a third party and would still be valid.

That’s why we wonder if it’s possible to add some more security by utilizing something like user or session id stored in a cookie and sent to the server for token creation and validation. Additionally, we would like to bind the token to a specific URL but without configuring all URLs explicitly in the custom VCL script. But if we could add something like the user id to the token, we probably can also add the URL and have a token validated for a specific user for a specific URL, right?

Some pseudo code: create_token(expiration, user_id, url, secret), validate(token, user_id, url, secret)

/some_url?token=1441307151_4492f25946a2e8e1414a8bb53dab8a6ba1cf4615
/another_url?token=1441307151_ e24b801c310567e96f84c3c33ad20e38fb10a7ac

Any help is greatly appreciated! We are quite new to this, so our idea might not be the best solution to our problem, which is restricting access directly on Fastly’s servers without an authentication/authorization backend.

Best regards,
Ian


#2

hey @ianfs would you mind shooting this over to support@fastly.com? We’d be happy to help out. Most likely will involve working with your service directly, so we want to make sure to keep that private.


#3

We think we might have found a good solution that I’d like to share with you guys for discussion:

  1. Users of our service go to www.ourdomain.com/landingpage.html.
  2. They log in with their credentials and we store a session cookie which’s value looks like this: <user-id>_<timestamp>_<sha256-hash>, where <user-id> is the plaintext user id, <timestamp> is the Unix time of expiration followed by a <sha256-hash> of the user-id, the timestamp, and a secret stored on our web server and in the VCL config.
  3. After a user successfully logged in, the above /landingpage.html shows links to subdomain.ourdomain.com which itself points to Fastly.
  4. The link like for example subdomain.ourdomain.com/subdomain-landingpage.html contains a token in the form of <timestamp>_<sha256-hash>, where <timestamp> is the Unix time of expiration followed by a <sha256-hash> of the user-id, the timestamp, the URL path, and a secret stored on our web server and in the VCL config.
  5. When a user navigates to a link on subdomain.ourdomain.com, Varnish will first verify the cookie.
  6. If the cookie is OK, Varnish will verify the URL token.
  7. If either of the tokens cannot be verified, the user will get redirected back to www.ourdomain.com/landingpage.html where the session can be renewed, links can be regenerated, and/or an error message can be shown to the user.
  8. If both tokens can be verified the HTML page will be delivered to the user’s browser. Subsequent requests for resources and other URLs not of type subdomain-landingpage will only contain the cookie, but still, the user can be verified this way.

@Taylor_Mello FYI, I contacted the support as suggested, the ticket number is 31782.