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/verify will be deprecated. You should move your application over to
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:
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.
v2/oauth/tokenendpoint 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-urlencodedand encoded as such in accordance with Section 4.1.3 in OAuth RFC (6749).
POST v2/oauth/token HTTP/1.1
Incorrect - Data sent as a JSON payload:
POST v2/oauth/token HTTP/1.1
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
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