If anyone gets hold of the client key and client secret they can start generating tokens and use them as desired.
Correct.
How can we prevent this ?
Your question is about securing the token acquisition process. You might think of it as the boot-strapping process. The OAuth token concept is valuable because the credential (the token) is short-lived, which means if it is compromised, the window of vulnerability is relatively low. If you make your token lifetimes 30 minutes, then a malicious party that obtains the token would have only 30 minutes to exploit it before the token becomes un-usable. This is handy, a good way to reduce the impact of a credential leak. but obviously that cannot be your only approach to security.
If you are concerned about the client id and secret leaking, I would challenge you to think about HOW. that might occur. Just what are you protecting against here? There are different possibilities, here are some I can think of:
- The client id and secret get distributed via an insecure mechanism, like email. In which case, an unscrupulous or corrupted (pwned) middleman might steal the id+secret and then be able to use it independently.
- the client is a public client, it runs on consumer devices, and there's no guarantee the users of these devices are trustworthy. Any hacker will be able to de-compile the client code and retrieve the id+secret embedded into the client.
- you're concerned about TLS zero-day exploits, or MiTM attacks, in which the id+secret pair get logged and exposed during normal use. The RFC6749 request-for-token transmits the id+secret pair, and some insecure link in the chain might intercept that request and leak the id+secret.
- there is an untrusted developer who has access to the id+secret and that person distributes the id+secret to some other party.
- some other supply-chain leak. For example a corrupted library that logs requests to a malicious sink, allowing a hacker to see all traffic sent by the client.
Each of these is different scenarios and might require different approaches.
One approach is to use a TLS certificate on the client side, and couple the id+secret to that TLS certificate. If your oauth endpoint receives a request-for-token that does not use the matching tLS cert, then ... you should reject the request-for-token. This is similar to, but slightly different than, what is known as "OAuth token binding".
If you're worried about the id+secret leaking during normal use, then you can rely on a RFC 7523 -style request-for-token, in which the secret is never transmitted. Instead the client forms the request-for-token as a JWT, signed using the secret as a key. This protect you against TLS zero-day exploits, or weak TLS ciphers, but won't protect you against untrusted saboteurs in your dev team, who leak credentials purposefully.
Rotating the client id+secret pair periodically can provide a failsafe against any of the above leaks. But it means you need to distribute new credentials fairly often.
For any sort of token mis-use, you should be monitoring traffic and use of the tokens to check for anomalous behavior, and then you should block the token (or the original id+secret) immediately and automatically. Apigee's Advanced API security is designed for that purpose.
Bottom line, you need to think systematically about the things you're protecting against, before taking steps to "Secure" the token dispensing endpoint.
LinkedIn
Twitter
