LinkedIn
Twitter
1 ACCEPTED SOLUTION
If you use a JWT Token as a bearer token, then any party in possession of that token can use it to get access to a resource. This is the definition of bearer token. It is like cash money. Any party in possession of cash can spend it; in most societies, there's no requirement to present identification to spend cash. The holder of cash is presumed to be the rightful owner of the cash. The same applies to bearer tokens.
From the OAuth specification on bearer tokens (RFC 6750):
It is not correct to say that if a token is intercepted or leaked, it has been "corrupted". A leaked token is not corrupted; it's still a valid, bona-fide token, and the signature on it will still verify. The token is good. Instead we'd say that it has been leaked or intercepted or disclosed.
If you use tokens as bearer tokens, then it's important to protect against leakage or loss. That means:
- take care with grant types. Perhaps use RFC7523 to require signed requests for tokens.
- apply rate limits to your token dispensing endpoints
- only issue tokens over TLS
- Using the expiry claim, keep token lifetimes low. For example, less than or equal to 30 minutes.
If this is not enough for you, you can also bind tokens to IP addresses, and if you use mTLS, you could bind tokens to client-side TLS fingerprints. "binding" means, when you verify the token, you could check the presenting IP address to verify that it is the same IP address that was used to issue the token. To make that happen, the token issuer must attach the client IP address as a claim before signing the original token.
Or you could do the analogous thing with the TLS fingerprint. At issuance time, Insert a claim containing the TLS fingerprint into the token, before signing it and returning it to the client.
IP address binding is not foolproof obviously. But it does reduce some of the risk associated to token leakage. TLS fingerprint binding seems like a belt-and-suspenders thing; if you have authenticated the client identity with mutual TLS, then.. the token is almost redundant if you are using the token to assert client identity. But using a JWT with a TLS certificate would make sense, if the token carries user-identity information, as opposed to just client identity information.
If you use a JWT Token as a bearer token, then any party in possession of that token can use it to get access to a resource. This is the definition of bearer token. It is like cash money. Any party in possession of cash can spend it; in most societies, there's no requirement to present identification to spend cash. The holder of cash is presumed to be the rightful owner of the cash. The same applies to bearer tokens.
From the OAuth specification on bearer tokens (RFC 6750):
It is not correct to say that if a token is intercepted or leaked, it has been "corrupted". A leaked token is not corrupted; it's still a valid, bona-fide token, and the signature on it will still verify. The token is good. Instead we'd say that it has been leaked or intercepted or disclosed.
If you use tokens as bearer tokens, then it's important to protect against leakage or loss. That means:
- take care with grant types. Perhaps use RFC7523 to require signed requests for tokens.
- apply rate limits to your token dispensing endpoints
- only issue tokens over TLS
- Using the expiry claim, keep token lifetimes low. For example, less than or equal to 30 minutes.
If this is not enough for you, you can also bind tokens to IP addresses, and if you use mTLS, you could bind tokens to client-side TLS fingerprints. "binding" means, when you verify the token, you could check the presenting IP address to verify that it is the same IP address that was used to issue the token. To make that happen, the token issuer must attach the client IP address as a claim before signing the original token.
Or you could do the analogous thing with the TLS fingerprint. At issuance time, Insert a claim containing the TLS fingerprint into the token, before signing it and returning it to the client.
IP address binding is not foolproof obviously. But it does reduce some of the risk associated to token leakage. TLS fingerprint binding seems like a belt-and-suspenders thing; if you have authenticated the client identity with mutual TLS, then.. the token is almost redundant if you are using the token to assert client identity. But using a JWT with a TLS certificate would make sense, if the token carries user-identity information, as opposed to just client identity information.
