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.
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.
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.
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:
An attacker that successfully breaks TLS on login.eveonline.com (by forging a certificate, compromising CCP server or whatever) would just steal everyone password when they log in. Sending fake tokens to third party apps would be a wast of time, energy and money.
In order to validate tokens, third-party apps need CCP keys. How do you suggest they get them?
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.
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:
an attacker able to do that will have user passwords anyway and
validating JWT won’t protect against such an attacker.
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.