How do I get the new API (ESI?) to provide to a corp I’m trying to join?
You log in to their tool through the SSO and accept the scopes (what it can see). You do this for all of your characters that you want to add.
Ok, so the corp needs to have an API validation tool?
The corp needs to use the new API, because the old one is gone now.
They need to have a web-based interface where you can give authorization via EVE’s Single-Sign-On service. It works just like you were to sign on with a Facebook or a Google account only it’s your EVE account.
Frankly, if you have to come to the forum and ask here, then your corp probably doesn’t even know that the old API has been switched off. Your corp should have given you a link where you grant them access instead.
Thanks!
Ok… so how does the corp management ask for the character SSO?
You don’t. SSO stands for Single Sign On, meaning you use your account logins to authenticate you are who you say you are, which then gives the program a token that proves you are who you say you are. The player then accepts the scopes (what that program can see about your character). This is character specific, no full account -API anymore.
This is how it works:
- All data is fetched from the ESI server.
- Protected data needs authentication, unprotected data does not.
- To get to the protected data does it need a security token. These tokens last for 20 minutes and can be refreshed.
- To get a first token does a player need to pass a cryptographic code to your web app. The code can only be had through a redirection after a player has signed on to CCP’s SSO service and is random, meaning, it is not specific or unique to a player.
This means for your application or alliance / corporation service to be web-based, or at least to have a minimal web interface for setting up an SSO session. Once a first session has been established can one get new tokens and use them to make repeated secure requests to the ESI server. You then only need to store the tokens (one for the access, the other for the refresh) in a database or a file and use it as you see fit. However, these tokens are cryptographic, meaning they are random, as well as bound to a client secret and id (stuff you get when you set up your app with CCP). These tokens therefore cannot be provided by a player as it used to be.
If you keep the tokens secure on your server and don’t pass them around then the new method is fairly secure - about as secure as a classic login/password check. Only does a player not need to know any security stuff, does not need any API keys, but can simply use their login and password via CCP’s Single Sign On service.
And yes, it may seem complicated and new at first for a 3rd party dev, but they should be able to handle it as it means less things to know for the rest of the players for when they use your corporation / alliance services.
That is the most insecure method I’ve seen. This is akin to taking a latop with zero security into a public wifi and doing online banking.
1 Like
Which part of the new system seems insecure to you?
Then you don’t understand how the system works
ESI data isn’t exactly super private anyway and its no less secure than the older API keys as you still needed people to keep the API key and vcode away from prying eyes
Then please explain
https://developers.eveonline.com/blog/article/sso-to-authenticated-calls
http://eveonline-third-party-documentation.readthedocs.io/en/latest/
https://developers.eveonline.com/
We also have a forum section for it:
1 Like
Is there a place where i can check peoples sso tokens. Jackknife’s SSO token checker doesn’t work for me for some reason.
If you just want to verify a token then you can do this:
http://eveonline-third-party-documentation.readthedocs.io/en/latest/sso/obtaincharacterid.html
Shouldn’t be too difficult to do it with a Python, Perl or PHP script. You only need to send a HTTP GET request.
There’s some pretty shoddy explanation of how OAuth2 works in here. I’ll try to do a quick summary:
There are three parties involved in the transaction:
- [A] you / your browser, serving as the “client”
- [B} your corp / their “key validation” website, serving as the “server”
- [C] CCP, serving as the “auth provider”
Step 1: The client [A] tells the server [B] they would like to authenticate. The server returns a special code to the client, and tells them to talk to [C] (redirects them).
Step 2: The client [A] talks to the auth provider [C], giving them the special code they got from the server. The auth provider verifies that [A] is who they say they are, and returns another code, an auth token, that represents this current “login”. [C] Then tells [A] to go back to talking to the original server [B].
Step 3: The client [A], now in possession of an auth token, talks to [B] and gives them the token. [B] can then use this token to talk to [C] to validate whether it is indeed a valid token (since [C] is the ultimate authority on who is or isn’t logged in).
Step 4: Assuming that validation goes through, that means that [B] can then ask [C] to call various parts of the API, using the token they got from [A] and whatever restrictions it has on it.
In practice, what you (the user) actually see is:
- You visit your corp’s page and click a button like this one:
- You see the standard Eve Online login page, where you log in and select a character. You also see some specified “scopes”, which are permissions that the website you are logging into is asking for (e.g.
esi-mail.read_mail.v1if it wants to be able to read your mail) - After you accept, you return to your corp’s website and it is now able to use information about you from the API.
This is industry standard SSO security, and the same sort of process (with some small variations) happens on any website that has a “Log in with Google/Facebook/Twitter/Whatever” feature. It’s far more secure and controlled than the old API (with its static and user-managed API keys), but it is significantly more burdensome for a developer to implement.
I may oversimplified a little bit (there’s an extra bit of abstraction so that only [B] party ever has access to a true auth code, plus some stuff about refresh codes), but if you want the full story you can read it over at the ESI docs or from the firehose RFC 6749 itself (look for implicit auth grants).
Source: CCP’s docs, plus building this stuff both in my RL job and in my free time using the CCP API 
So you thought let’s nerd this up with As, Bs and Cs.
Please remember where you are. This is GD, “shoddy” is fine. Less is more.
Could an ISD please move this into the right forum section? @ISD_Fractal, please?
What, should I have gone with Alice, Bob, and Charlie?
OK, let’s try that, answering the OP’s question:
The new API system works through the main Eve web login page and no other way, so if a corp is talking about API keys they don’t know what they’re saying. “API keys” don’t exist anymore. If the corp you’re trying to join is still asking for an API key, you need to tell them to “git gud” and find another corp. 
2 Likes
The OP had his question answered, but since the conversation is continuing into more technical aspects I have moved this thread to a more appropriate location. Cheers @Whitehound.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.