Third Party Developer Blog

SSO Endpoint Deprecations

Hi developer friends!

We'd like to inform you of upcoming SSO changes which might affect your application if you are developing 3rd party apps using ESI or using the EVE SSO for user authentication.

We'll be making the following changes on November 1st 2021.

Deprecating obsolete endpoints

The old OAuth endpoints oauth/authorize, oauth/token and oauth/verify will be deprecated. You should move your application over to v2/oauth/authorize and v2/oauth/token instead. The oauth/verify endpoint will also be deprecated, since the v2 endpoints return a JWT token, enabling your applications to validate the JWT tokens without having to make a request to the SSO for each token. Applications can fetch the required EVE SSO metadata from https://login.eveonline.com/.well-known/oauth-authorization-server to be able to validate JWT token signatures client-side.

The deprecated endpoints might be removed at any given time after November 1st 2021!

What about our old refresh tokens?

Existing applications can do a one-way-upgrade on their existing refresh tokens by sending them to the v2/oauth/token instead of oauth/token endpoint to upgrade them to v2 tokens. Make sure to replace the stored refresh token with the one returned in the response! Once an old refresh token is upgraded to a v2 token, the old token is invalidated and no longer usable. This upgrade mechanism will only be active for two weeks after the release.

You can tell the new refresh tokens apart from the old ones as they are a 24 character strings (16 bytes Base64 encoded).

V2 Refresh token example: MDEyMzQ1Njc4OWFiY2RlZg==

Stricter OAuth conformance

Developers will need to follow the OAuth specification more closely when sending data to the SSO token endpoint. In short, to ensure that your application continues to work with the EVE SSO, you should follow the official EVE SSO guidelines.

Here are some important points to be aware of:

• Native/mobile applications should use the PKCE flow as described here.
• Web/server-side applications should use the authorization code flow as described here.
• The v2/oauth/token endpoint will no longer accept data sent as a JSON payload or as a URL query. Data must be sent to the endpoint with Content-Type: application/x-www-form-urlencoded and encoded as such in accordance with Section 4.1.3 in OAuth RFC (6749).

Correct:

POST v2/oauth/token HTTP/1.1
Host: login.eveonline.com
Content-Type: application/x-www-form-urlencoded

client_id=someawesomeclient&grant_type=authorization_code&code=exampleauthorizationcode&code_verifier=codeverifier&redirect_uri=https%3A%2F%2Fmy3rdpartyapp%2Fauth%2Fcallback

Incorrect - Data sent as a JSON payload:

POST v2/oauth/token HTTP/1.1
Host: login.eveonline.com
Content-Type: application/json

{ "client_id":"someawesomeclient","grant_type":"authorization_code","code":"exampleauthorizationcode","code_verifier":"codeverifier","redirect_uri":"https://my3rdpartyapp/authþ/callback"}

Incorrect - data sent as a querystring:

POST v2/oauth/token?client_id=someawesomeclient&grant_type=authorization_code&code=exampleauthorizationcode&code_verifier=codeverifier&redirect_uri=https%3A%2F%2Fmy3rdpartyapp%2Fauth%2Fcallback HTTP/1.1
Host: login.eveonline.com

Use a standardized OAuth JWT validation library

Developers should use a standard OAuth JWT validation library to be prepared for upcoming changes in the SSO such as different JWT signature methods. Libraries exist for pretty much all programming languages out there. See JWT.IO for more information and an SDK for your programming language of choice!

Prepare for refresh token rotations

Developers have until now been able to safely assume that their stored refresh tokens will never change. This will no longer be the case, so developers should assume that the refresh token MIGHT change when it is refreshed and update it when needed.

Rate limits for failed requests

We'll be introducing a rate-limiter that will kick in when an application exceeds a certain threshold of failed requests. When it is triggered a 429 Too Many Requests response will be returned. This is to encourage developers to clear old/invalid refresh tokens from their databases as well as make sure their applications are well tested and conform to the OAuth specification. Applications that repeatedly trigger the rate-limiting and don't respect the Retry-After header might get their applications blocked by the EVE SSO for API Abuse and require a support ticket to be reopened

back