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).
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 
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.
I think it would make sense to validate the tokens if these are provided by an untrusted source (e.g. provided by the user).
Well, I hope ESI servers validate tokens we provide them when we make an authenticated call 
.
An app that gets token from its users (instead of from SSO) could also validate tokens. It would save it from getting 403 errors on ESI calls at the cost of SSO calls to get the keys. Not sure thatâs a common use case though 
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.
I think Iâm already doing this. I donât think the SSO provides different tokens that the requested ones at the moment, but maybe it will do it at some point, who knows.
One benefit of validating tokens (which validates the signature) is that CCP Games can now rotate their private keys
They already can. The tokens are only valid for 20 mins, so during regular operation it takes CCP 20mins to rotate its keys.
If your application does not validate tokens then [âŚ], at best, [it] would send useless traffic to the ESI that all fail
Well, in case of an emergency (less than 20mins) key rotation after a breach, the best way for third-party app to know about it is to wait for 403 errors on ESI calls. The only other option is to query the SSO for the keys before each ESI call, wich would be much more expensive, and wouldnât even work in some cases.
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
I believe we (third-party app developers) cannot do anything against such actor.
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.
Right. I said the tokens we get are very unlikely to be invalid because we retrieve them through TLS. Obviously, TLS can fail and there is still a risk. But:
This is not key rotation.
No. They are never rotated in regular operation. I have the CCP public keys from months ago. I just checked again. They are still:
[
{
"Alg": "ES256",
"Id": "8878a23f-2489-4045-989e-4d2f3ec1ae1a",
"Kty": "EC",
"Use": "sig",
"Crv": "P-256",
"X": "PatzB2HJzZOzmqQyYpQYqn3SAXoVYWrZKmMgJnfK94I",
"Y": "qDb1kUd13fRTN2UNmcgSoQoyqeF_C1MsFlY_a87csnY"
},
{
"Alg": "RS256",
"Id": "JWT-Signature-Key",
"Kty": "RSA",
"Use": "sig",
"E": "AQAB",
"N": "nehPQ7FQ1YK-leKyIg-aACZaT-DbTL5V1XpXghtLX_bEC-fwxhdE_4yQKDF6cA-V4c-5kh8wMZbfYw5xxgM9DynhMkVrmQFyYB3QMZwydr922UWs3kLz-nO6vi0ldCn-ffM9odUPRHv9UbhM5bB4SZtCrpr9hWQgJ3FjzWO2KosGQ8acLxLtDQfU_lq0OGzoj_oWwUKaN_OVfu80zGTH7mxVeGMJqWXABKd52ByvYZn3wL_hG60DfDWGV_xfLlHMt_WoKZmrXT4V3BCBmbitJ6lda3oNdNeHUh486iqaL43bMR2K4TzrspGMRUYXcudUQ9TycBQBrUlT85NRY9TeOw"
}
]
Weâre talking about validating a JWT here.
You canât tell a 403 difference due to a user legitimately revoking your token, or CCP rotating their key and invalidating tokens that way. Validating a JWT isnt for making sure an access token is still valid.
What validating a JWT will do is allow your application to smoothly recover from a situation where you are just-completed requesting new JWTs and CCP has rotated their keys.
It will protect you from buggy authorizations should CCPâs server misbehave.
It will protect you from people who have compromised any sort of network between you and CCP Games and are able to alter the JWT.
It will protect you from cosmic ray bitflips.
It will be a defense-in-depth in case the TLS connection is MITMâd (hello, China users).
Optionally, you can monitor CCPâs public key endpoint to detect when they change and make your application behave more graceful.
That is not every malicious (or non-malicious, âlegalâ government-permitted MITM of TLS) actorâs goal when compromising TLS. This is an assumption.
You get them from CCP at https://login.eveonline.com/oauth/jwks
I never said it was 
I never said they were rotated. I said it takes 20mins to rotate them.
You can. In the former case the refresh token is no longer valid, in the later it is still.
That looks useless.
Yes and no. It wonât protect me. It will avoid me getting 403 errors. If I get some, would it cause me any issues?
As I said:
I honestly donât get your point here. Which goal are you referring to? Iâm saying itâs easier to steal passwords than to send forged tokens. People will always take the easiest path to their goal, whatever the goal is.
Yes, I know. My question was how I can trust this endpoint.
I sincerely donât think you understand what key rotation means.
When the JWT key is rotated, end users should assume all access and refresh tokens validated by the old key are invalidated, as rotation could have been for any reason and old JWTs wonât validate anymore anyway.
This has nothing to do with whether CCP decides to send you 403s.
No. In the latter case you assume refresh tokens are compromised and do not use them. Again, go beyond the 403 thinking. Youâre stuck in the OAuth flow, JWT as a solution is larger than that.
Look man, forget about the access and refresh tokens. You keep confusing everything together. Key rotations have nothing to do with them. Key rotations are about changing the JWT signing key. Now, when this happens, it means at a practical level all existing JWTs will fail signature validation from that point on. the access and refresh tokens could 403 or could keep working.
However, if you validate JWTs and notice a key change, since your existing JWTs now fail anyway itâs a good time to refresh them. It just so happens that means going through the OAuth flow, but thatâs a side note. It is good practice because your JWTs are invalid anyway, and you have no idea if it is because of a compromise or not. People who donât care about validation will happily accept expired, invalid, or otherwise maliciously signed JWTs. The access and refresh tokens could be valid, maybe not. Because the validity of those tokens is an independent issue.
You keep trying to tie the two together and say âdoesnât seem usefulâ. Well, yeah, when you erase the point of a JWT by focusing on anything else, then demand it prove itself useful, itâs kind of a âno duhâ that you donât see value in it.
JWT and OAuth are composed together. Each tackle different things for different reasons. Protocol designers make those choices on purpose to solve problems. Read up on JWTs alone if it helps.
Yes, and I am saying âstealing passwords is easierâ is a bad faulty assumption. A disgruntled employee at CCP might surreptitiously steal 1 private key easier than a whole encrypted DB worth of passwords.
You canât assume one way is easier than the other, and then base your whole appâs security model of what you think all bad actors would do. Youâre not thinking of enough threat models.
More like: how can you not?
If you canât trust this endpoint then you certainly canât trust TLS. Each relies on saying âI am the authoritative source of validation keysâ, TLS just happens to be in a chain of âI say soâ instead of CCPâs one âI say soâ. Your dividing lines of distrust are really weird and unintuitive.
Oh, Okay. We have a misunderstanding here. My question is not âGeneraly speaking, why should JWT tokens be validatedâ. Obviously, thereâs a number of case when they need to. The most obvious I can think about is that ESI server MUST validate those they receive from clients. More generally speaking, servers need to validate tokens (JWT or not), but I donât see the point for clients.
My question is âAs an third-party application developer, why should I validate access token I receive from EVE SSO?â The ESI doc states I should do it, but I donât get how this will enhance my app security.