Let me explain the complete implementation methodology and problem statement

URL to be protected
http://site.media.com/mediafiles/movie.m3u8

We are generating token on application/client side to send it along with request so that content is delivered by server only to authorized apps.

Token Generation Methodology on App/Client

expire = Current Epoch Time on App/Client + 600 ( 600 so that URL will be valid for 10 mins)
uri = mediafiles/movie.m3u8
secret = secretkey

On Client , MD5 Function is used to generate token by using three above defined values
token = MD5 Hash ( secret, uri, expire)

Client passes generated token along with expiry time with URL
http://site.media.com/mediafiles/movie.m3u8?token={generated value}&expire={value in variable expire}


Token Validation on Server
Token and Expire is captured and passed through secure link module

location / {

secure_link $arg_token,$arg_expire;
secure_link_md5 "secretkey$uri$arg_expire";

//If token generated here matches with token passed in request , content is delivered
if ($secure_link = "") {return 405;} // token doesn't match

if ($secure_link = "0") {return 410;}
//If value in arg_expire time is greater current epoch time of server , content is delivered .
Since arg_expire has epoch time of device + 600 sec so on server it will be success. If someone tries to access the content using same URL after 600 sec , time on server will be greater than time send in arg_expire and thus request will be denied.


Problem Statement
Someone changes the time on his client device to say some future date and time. In this case same app will generate the token with above mention methodolgy on client and send it along with request to server.
Server will generate the token at its end using all the values along with expire time send in URL request ( note here expire time is generated using future date on device)
So token will match and 1st check will be successful .
In 2nd check since arg_expire has epoch time of future date + 600 sec which will be obviously greater than current epcoh time of server and request will be successfully delivered.
Anyone can use same token and extended epoch time with request for that period of time for which future date was set on device.

Hopefully now its explainatory .
Please let know if there is a way to protect the content in this scenario.