1

enter image description here

This is a typical token-based auth sequence. The initial sign-in sends username/password, receives a token that is used for all subsequent requests. The tokens are only valid for a set amount of time.

If there was a malicious listener on the network that sniffs a token, they can impersonate the client, but exposure is time-limited. But if there was a listener on the network who can sniff tokens, wouldn't they be able to sniff the initial sign-in request and continue to request their own tokens forever?

At that point doesn't the whole setup devolve to the equivalent of sending an irrevocable API key with every request?

RaGe
  • 22,696
  • 11
  • 72
  • 104
  • 1
    It would be subjective to the client type and API key method you are referring. However, API keys were never designed to be secure and should not be considered as such. SSL would be required for either API key or JWT methods, to ensure the request/response is encoded and not as susceptible to MITM. However, for immutable query string API keys, they can be exposed in the client browser history and server access logs. – Will B. Sep 02 '21 at 04:59

1 Answers1

1

I would say the key benefits of JWTs are around the security ecosystem and design patterns it gives you. Much of this behaviour is implemented by an Authorization Server and reduces the work you need to do:

  • JWTs are time constrained as you say, meaning that for all scenarios other than those where there is an edge case of a permanent listener, they are more secure.

  • Internet clients should use confidential access tokens that do not reveal any confidential data - it is common to use reference tokens (eg UUIDs) - see the Phantom Token article for how this works.

  • JWTs encourage patterns where APIs receive digitally verifiable scopes and claims that can be trusted and used for authorization - whereas an API key could easily grant access to too much data.

  • A mechanism for both user friendly sessions and revocation in the face of data breaches is provided by using refresh tokens and access tokens together. Eg an access token only lives 15 minutes while a refresh token lasts 8 hours. Apps have to check in with the Authorization Server every 15 minutes, but this only rarely impacts the user.

  • Token issuing is audited in a database (along with user consent if relevant) and available after the event - eg for your InfoSec staff.

  • JWTs can be sender constrained in some scenarios, such as for financial grade connections between business partners, so that an attacker cannot use a token that they intercept.

An API key could actually be designed to work like a reference token, since they feel the same to a client. You would then need to do a lot of custom work in your back end though. Whereas a free Authorization Server will do this work for you.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24