Why validate JWT tokens?


The ESI doc regarding SSO states:

Your application should validate the access tokens received from the EVE SSO.

But why? How can an access token possibly be invalid? I mean, applications are supposed to fetch them from https://login.eveonline.com/v2/oauth/token. In which case would this endpoint return invalid data? It is using TLS, which makes in transit tampering very unlikely.

Yes, it’s not really needed. On top of that there are SSO libraries that are not compatible with EVESSO’s JWT, since it’s missing https, so even if you want to validate, you may not be so lucky that is easily possible. Still, you should validate the access token, if it’s possible, if nothing else to learn how to do it.

I’ll concede you learning is fun, and I would totally understand a developer who would write JWT validation code just for the sake of it.

However, in my opinion, said code should NOT make it to production unless it increases security (which doesn’t seem to be the case here).

  • Increasing app size and CPU/RAM usage should always be weighted against the benefit it provides.
  • If there is a bug in the JWT validation code that makes it return “valid” on invalid tokens, the author will never know it (and therefore never learn from the mistake they made).
  • If there is a bug in this code that makes it return “invalid” on valid tokens, the app will break in production (which already happened).

So unless someone explain me why its useful to validate tokens in production, I won’t do it.

OK, that is perfectly fine

Sorry if I sounded aggressive :slight_smile:

I posted this thread to find out whether I missed something in my analysis that validating token is pointless, since the doc states otherwise. So thank-you for confirming.

But do you check the certificate to make sure you are connecting to the host you intend to connect? No. So, what is the the purpose of TLS in your case? Giving you false sense of security. Which is the entirety of the TLS infrastructure today. Nobody’s actually paying attention to what they are connecting to. They blindly trust the lock icon and go ahead.

But do you check the certificate to make sure you are connecting to the host you intend to connect? No.

??? What makes you think I’m not?

Also, how do you expect me to get the keys for token validation?

Because nobody does that. Everybody blindly trust installed root certificates for host verification.

So you are trolling. Well, I’m not interested.

I’m stating the fact. The ONLY place where I’ve seen this kind of checking done right is internal TLS infrastructure at my workplace. Not only root certificates are chosen explicitly, but server’s CN and SAN are tested as well as certain OID’s.

@CCP_Zoetrope according to GitHub you are the one who recommended validating SSO tokens in ESI clients. Do you remember the rationale for it?

I think it means you should verify that the JWT is valid: sig, iss, exp, aud. There are libraries that are just a couple KB in size that can accomplish this.

I find it odd to state you should verify tokens from the SSO. I think it would make sense to validate the tokens if these are provided by an untrusted source (e.g. provided by the user).

One thing you must validate are the scopes contained in the token — you should not make ESI calls that do not have the required scopes.

Valid suggestion.

One benefit of validating tokens (which validates the signature) is that CCP Games can now rotate their private keys in case of a breach in their system by a malicious third party and ideally every third party app in the ecosystem should invalidate and no longer use breached tokens, with seamless non-error behavior – annoying behavior like “individual has to re-auth” is WAI.

If your application does not validate tokens then it would never know about the key rotation and, at best, would send useless traffic to the ESI that all fail, resulting in errors in your application. The worst case depends on how your app is written against a hostile threat actor that is able to issue your app CCP-Games-valid but malicious tokens – and if you weren’t validating in the first place, the “Defense in Depth” principle isn’t at play, so whatever single security element you’re relying on becomes that much more critical as a single point of failure.