If you are unfamiliar with EVE online you can skip this rant. If you do play EVE online here’s a quick intro to the current state of APIs.

CCP’s massively multiplayer online game EVE Online provides its players with what is probably the biggest set of 3rd party integrations there are. Programmers can use three different APIs to retrieve real in-game data. There’s an XML API, a CREST API (JSON that is crawlable), and lastly a ESI API that is built on swagger.

Of these API’s two (XML and CREST) are deprecated and slated for removal around May of 2018 before which the ESI API will gain feature parity with its predecessors.

To authenticate against these API’s there are API keys (pre shared secrets) for the XML API and an OAuth2 Authorization Grant Flow to retrieve tokens with scopes for the endpoints on the CREST and ESI API’s.

My rant is about security issues specific to this OAuth2 server which is named the SSO (single sign-on) in relation to talking to the ESI API which will be the only available API starting 2018.

When using the SSO an application requests the user to log in to the EVE Online website, accept the scopes (permissions for certain endpoints) requested by the application and is then sent back, authorization code in hand, to the requesting application’s callback URL.

The application issues a request with the received token to gain a refresh token. This refresh token never expires and allows the application to request 20-minute valid access tokens.

Third Party Application Management

A user can remove access tokens by going to their account management (I had a hard time finding this link but if you Google just right it’s doable) where they are presented with the following screen:

Names protected for the innocent.

Here-in lies my first issue. The management of the applications you have allowed to access the EVE Online API’s on your behalf is a total shit show. This is caused mostly by the fact that the same application requesting different scopes at different times will have the application show up multiple times in your third party applications list. That list is then spread out across the number of characters on your account.

The ‘application requesting different scopes at different times’ is a common idiom due to the fact that the ESI API is still under active development and scopes are being added on a weekly basis. This issue might negate itself after feature parity is achieved.

Character Transfers

In EVE Online it is possible to sell characters, when a character is sold a fee is paid to CCP and the character gets moved from one account to another. This usually means a change of ownership for the character.

In the old authentication method of a pre-shared key on the XML API the key was account based.

based. In the new authentication method of an SSO refresh token the token is character based.

A sidenote to this is CCP’s adamant denial of allowing anything to identify what account a character belongs to.

When a character gets transferred the SSO API does not invalidate any of the refresh tokens available for that character.

This means that when you buy a character from someone else that has previously authorized any applications to use the API in the name of that character that these applications still have access to that information.

These third party applications do not appear on the Third Party Application list after a character transfer.



After a character transfer the applications that still have refresh tokens for that character are invisible to the new owner.

From an EVE Online standpoint this allows for some creative spy crafting going both ways. Firstly I can sell someone a character which has granted my application everything and then keep tracking the character. Secondly alliances that employ authentication systems which allow users to log in with their EVE account need to be very careful if they allow all alts to login to the same account or not.

Due to CCP’s EULA we are not allowed to use any SSO tokens for causes that they weren’t requested for. That clearly implies that we need to get rid of SSO tokens after they belong to a character that does not belong to the owner that has granted us permissions.

Luckily the SSO development team tried to give us an option to verify if a character still belongs to a certain account.

There’s a method an application can call which returns a value called the accountHash which is a supposedly unique identifier for an account. Multiple characters on the same account should not share the same account hash so it’s still impossible to relate characters through this. It could however be useful for application developers to tell when a character changes accounts so we can remove the tokens for this character.

The accountHash does not change when a character gets transferred.

OK. Nevermind it doesn’t actually function at all, why is that even there?

Usability

This is a more minor gripe of mine but has been reported before and it is something that does annoy me as I need to explain it to users multiple times per day.

When you login a character through SSO you are presented with the following screen (after the username, two-factor, and password input):

Allowing you to select a character. There’s one minor issue and that is when I want to use a character from a different account there’s no easy way to tell how to swap (hint: you hit the cancel button). It is quite common for me to quickly swap accounts when adding multiple alts from different accounts to the same system.

However, this is severely hampered by the fact that this is the screen that follows the cancel button:

If you got stuck here, here’s the way to get around that:

Hit your browser back button

Hit refresh

You should now be presented again with the login screen and can continue your quest. This last issue was reported a few months ago.

State of the SSO

The general ecosystem that is being created by the team working on ESI and the team working on the SSO is very valuable. It’s a much better system than what I’ve seen the past 7 years of playing EVE online.

Sadly there is a huge difference between the SSO team and the ESI teams engagement with third party developers. The ESI team is around, answering questions in #esi on the Tweetfleet slack. At the same time the SSO team is ritually burning kittens in front of their door to make sure that no one ever contacts them.

The above issues are by no means a complete pictures of the way the SSO team is hampering third party development. Other issues are much more technical and not as obviously weird for a non-technical crowd. For a more complete overview you can read the last CSM minutes of the summit for the meeting with Team Tech Co.

Please, SSO team, come hang out in #esi (or #sso) in Tweetfleet slack. Read your issues. At least let us know you are working on these important things.