Ask the owner of the information if they authorize the request.
As Neil Smithline points out in his excellent answer to this question, the RFCs on JWT, OAuth, and many other token-based authentication systems rely on the end user maintaining the secrecy of their token.
For me personally, this is a hard pill to swallow: a lot of end users don't understand what a token is or even where it is, let alone why or how they should secure it.
While this may sound so fundamental it's belittling to point out: if an end user is aware someone is attempting to access their private information, or if an end user is aware that the privacy of their key has been compromised, one could argue they are significantly more likely to alert interested parties that something has gone wrong.
So, one might conclude the task at hand is to design a system whereby it is easy for end users to be aware of when their private information is being accessed, when their token is being used. While we can't design a system that doesn't rely on trust, we can design a system that ties protection of the key into interests that the user already has and knows how to manage.
In a hypothetical implementation of a system that uses web tokens, one might experiment with the following:
- Run tests on the application's infrastructure that ensure it is using Perfect Forward Security.
- Ask clients who access the application's infrastructure who they are.
- Look up the identification provided by the client in an internal system that maps the identification to a cell phone--and contact that cell phone.
- The message sent to the phone will provide as much information about the client as possible, and ask the person in control of the phone whether the client should be authorized to use the application infrastructure.
- If the client is authorized by the person in control of the phone, issue a token to the client and keep a record of how the token is used. Furthermore, share pertinent parts of that log with the phone on record.
- Expire the token after a short period of time; reject any further requests using that token.
While the steps above certainly aren't part of RFCs on JSON Web Tokens, OAuth or many other token-based authentication systems, it partially moves the issue of trust from a user who doesn't know how to keep a token secure to a group of engineers who ideally know how to implement two-factor authentication well.