When a user signs in they receive a authorisation token that is then sent along with each subsequent request to authorise the user, and the token is refreshed every server call or once per minute. I heard about attacks where the tokens were stolen and used by an attacker and that one way to mitigate this attack is to tie the token to the device. So what are some secure ways of tying the token to a device without inconveniencing the users?

For example using the IP address isn't optimal since users might want to switch between different networks without being signed out. And using the User-Agent doesn't seem as secure since attackers might know or be able to guess it and copy, but maybe I'm wrong about that.

The question Browser session cookies stolen/copied to another PC, why websites not smart enough prevent it? tackles the same issue but is more about why to bind the session rather than how it could be done.


2 Answers 2


You could tie the access token to a private key securely stored on the device. OAuth has two options for this:

  • I'm not using OAuth and it seems like these solutions could introduce more complexity if I was to implement them into our own auth flow. I've only skimmed through the pages so far though.
    – n-l-i
    Commented Jun 21 at 6:04
  • 1
    @n-l-i the same principles remain. You can use a client certificate on the device, and either present it in the TLS negotiation (so within https) or use it to sign a token to demonstrate the device has the private key.
    – jcaron
    Commented Jun 21 at 8:39
  • Yes, you could use the same claims for tying your access tokens to a public key even if you use another workflow for provisioning the tokens.
    – ysdx
    Commented Jun 21 at 11:44

If a more robust solution such as certificate verification isn't feasible for you, then you could look at some kind of browser fingerprinting as partial fix. By combining various bits of information about a visitor (User-Agent, installed plugins, language, country, installed fonts, adblocking rules, screen resolution etc) you can build up a fingerprint that, while not necessarily unique, is quite a bit harder to spoof than something simple like just the User-Agent.

It's certainly not bulletproof - but it could provide you an extra level of protection without introducing the complexity of something like client certificates. Whether that's "secure enough" for you depends on your threat model.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .