I was away from the game for 2 year and just realizes there is new system in place. I understand its SSO based after skimming the documentation, but I really just want to know 2 things:
Is a data transfer from my character from the API dependent on an associated login to eve AUTH backend, or is the auth token persistent once it has been granted - if so, for how long? How would zkillboard etc. manage data polls without persistent access (as with old API keys). If it is persistent, how is it managed by the user, can I revoke it somewhere?
For most endpoints, yes. There are some public endpoints for basic data.
For killmails, market transactions, wallet, evemails, etc. you have to explicitly grant access to the relevant scopes, after logging in on the EVE auth system.
There are 2 tokens, access token (valid for 20 minutes) and a refresh token (which can be used by the thrid-party app indefinitely).
Note that revoking access for zkillboard doesn’t stop it getting your killmails/lossmails if the Corp/Alliance exec have given permission for the corp or alliance killmails.
Additionally, it doesn’t stop zkillboard from access killmails you were involved in, where the final blow or the victim have given zkillboard permission.
Additionally, all war related killmails are public, so even without SSO permission, zkillboard can access any war related kills/losses you are on.
Revoking access on sites that were given authorizations seems silly and a failed security design.
CCP should add these access overviews under the account management or make them more apparent. When I was searching I got lots of developer docs, but no user access site (which is way more important). It is too obscure and at the end of the day you give permissions to the char data.
Anyhow thanks, at least I got what i was looking for
Why? If you gave them authorisation, then that’s on you.
Only give authorisation to sites you trust or get value from.
Additionally, it’s only character information. What’s the security failure? There’s nothing real about you as a person that any thierd-party app or developer can access.
It is a failed security design, because they are delegated that authorization by the CCP token. Only if I tell CCP to revoke it, it is enforced.
Whatever I tell the user of that token (the third party application), he may or may not honor, it is not transparent to the end user anyways.
When I say “security” I obviously mean in the context of the Eve world. That is a valid context, otherwise SSO would not have been set up in the first place.
Logically that is the only design that would make sense.
You had the same dilemma under the old paradigm. You could ask a dev/webmaster to remove your api key, but you had no way of knowing that it was removed. If you wanted to be sure that the site was no longer making use of the key that you provided them, you could log in to the eve API key site and delete it. (Assuming it wasn’t that the full API key that you couldn’t delete)
Now the only difference is that the work of generating the key is automated, and you have more chances to give informed consent about the data that you are handing over.
It is also much more secure now for the following reasons:
There are actions that you can take that will automatically invalidate all oauth grants linked to your account such as changing the account password.
Unlike API keys, tokens are not easily sharable. I won’t say its not possible, cause where there is the will of a bad actor they will find a way. But before, when you gave out an API key you could be 90% sure it was compromised unless you really trusted the person you were giving it to.
On a corp management level, you are no longer giving a key to someone that will just go store it in a google sheet in plain text to do API cheks with (yes this was a common thing)… you are now signing up to a site that is getting a limited use token which is easily revoked.
TL;DR in any API situation the authoritative source will always be the only source to trust when it comes to controlling access to your data. If you don’t trust the site, you should not be giving them access to your data, regardless of their method of accessing it.
