php - auto login by requesting security token -

scenario:

clientwebsite can accessed when user has security card inserted pc. clientwebsite outside of control, w/ security card.

i developed js web app requires username/password. system requests security token, , if provided credentials valid, token returned , appended requests url parameter. token valid 60 mins.

the sys admin of clientwebsite wants put link js app on secured site. if able view clientwebsite, allowed view js app, , after following link, should not have login again.

i had sys admin insert test link point page on our server , execute js/jquery retrieve http referrer, blank. conclusion -- our client's browsers have referrer disabled, or clientwebsite configured in way disables sending referrer. not surprising, secure site least.

it easy request security token via ajax/php before leaving clientwebsite (i provide code sys admin put in clientwebsite). method use hard coded credentials in php script, return/append token link it's available when arriving @ js app. js app check token's validity, , if ok, login suppressed on js app.

problem:

someone c/p ajax call clientwebsite, run outside of clientwebsite, obtain token, pass token else use access js app.

question:

i'd check referrer in php script, issue token if referrer matches clientwebsite, no referrer being sent & referrer can spoofed anyway. other method use determine request token coming clientwebsite page?

thanks!!

edit:

supply sys admin ajax call so:

$('#jsapplink').click(function(e){     e.preventdefault();     var currenthref = $(this).attr('href');     $.ajax({         "type":"post",         "datatype": "jsonp",         "url": "https://mydomain.com/gettokenusingcurl.php",         "success": function (returndata){             newhref = currenthref + "?token=" + returndata.token;             window.location = newhref;         }     }) }) 

onclick, php script on server queried. script contains hard coded creds. out of public view. return token clientwebsite, append js app url, continue link click routing user js app.

there 2 layers of defense need prevent style of attack.

the first use ssl prevent attackers off-system intercepting transmission , getting token. sounds may doing potentially (referrers blank ssl enabled pages).

the second introduce randomizing component (to differentiate requests each other) , identifying component (to identify user) token.

so, can have clientwebsite issue back-channel request server token. in request, should include remote ip of user, , should validate request coming clientwebsite's servers.

then, instead of returning token directly, encrypt using random nonce. associate nonce in database provided remote ip of user.

now, when browser makes request site, passes encrypted token. lookup key remote ip of user (remote_addr) , decrypt it.

it prevents replay attacks, since require ip spoofing able so. careful if proxies involved, complicate things (and proxy trusted instead of user).

this reminiscent how oauth1 works, except orientation of trust reversed (the client server auth source of record, in oauth authentication server auth source)...

/---------\            /---------------\           /-------------\ | browser | ---------> | clientwebsite |    ip     | server | |         |            |    server     | --------> |             | |         |            |               | encrypted |             | |         |            |               |   token   |             | |         |            |               | <-------- |             | |         |  encrypted |               |           |             | |         |    token   |               |           |             | |         | <--------- |               |           |             | |         |            \---------------/           |             | |         |                                        |             | |         |             encrypted token            |             | |         | -------------------------------------> |             | |         |                                        |             | |         |             session start              |             | |         | <------------------------------------- |             | \---------/                                        \-------------/ 

it's secure because way generate encrypted token (encrypted strong random key, never leaves server) make request clientwebsite's server (because you're verifying request came server directly, via back-channel).