If you use a JWT as a Bearer token, then it is a ticket-to-ride. According to convention, systems should grant access to any party that presents that token. In that way, the token is like cash money; if you hold the cash, then you can spend it. You don't have to prove it's "your money". You just hand it over and a store or seller will grant you rights based on your possession of the cash. (a token is unlike cash money in that a token can be re-used, presumably for many different requests, while cash can be spent once. But i hope the partial analogy works for you).
The practice of using OAuth 2.0 Bearer tokens, and the exposure and risk associated to token leakage, is independent of whether you use Apigee. A leaked or compromised Bearer token... means the holder can now impersonate the original holder. So... take care not to allow your tokens to leak! That means doing the usual things:
- don't record tokens in log files
- don't allow them in URLs (use the header!)
- don't expose them in the UI for operators to see unnecessarily.
- And also, protect your system in case a token should leak: make the token lifetime short (10 minutes? 5 minutes) so that the window of exposure is smaller.
All of this applies whether or not the token is a JWT or an opaque token. These risks happen if the token is used as a Bearer token.
What if you want to protect yourself, or your system, further? There are some approaches.
- Bind a token to a network element. For example, use 2-way TLS, and bind the token to the fingerprint of the certificate the client presented in TLS negotiation, during the original request-for-token. In this case, the token issuer can issue the token, and remember the fingerprint (maybe even embed the fingerprint into the payload). When the client presents the token again, asking for service, the verifier can check that the client-presented certificate is the same as that used during initial token request. This doesn't prevent leakage, but it does "bind" the token to the client-side TLS cert, which means you'd need to have leakage of both TLS key + cert as well as the token itself. This may be of benefit to you. Caveat: it works only if you can use mutual TLS for the connection (usually, that means it works only for managed clients).
- Don't use bearer tokens. The bearer token can be stored and re-used. An alternative approach is to use a token that is unique for each request. This might be an HMAC on the message payload, or on some digest of the message. For examples of this see Hawk, HttpSignature, or the AWS v4 cascaded HMAC signature approach. (Google Cloud uses a cascaded HMAC as well for cloud storage and I believe in other places) . The result of any of these is a unique, timestamped, expiring signature that is bound to each request. It cannot be "leaked" because ... it's unique. a malicious party could not reuse the signature with a different, future request.
- use a POP token. This is similar to the TLS approach, except the key can be handled at application layer, not transport layer. To make this work, you need to have some way to insure the key the client is presenting is trustworthy. In other words a mutually trusted key dispensary. And then the client needs to use that key.... perhaps to sign or encrypt its request (as with HttpSignature or HMAC). Check this prior article for some details.
More resources
LinkedIn
Twitter
