Authorization failure when token is too long

[BitSec01]

Bug

Make your application request an access token using all scopes currently available and then use that token on any endpoint.

Make sure you are logged in to https://login.eveonline.com beforehand.

Request

First authorize yourself using SSOv2 and ALL scopes available.
Then make an request to any endpoint using the token you got.

Response

{ "error": "authentication failure" }

Workaround

Just don't request all scopes. It is highly unlikely that you would need them all.

Expected

The output of the endpoint you are sending your request to.

Checklist

Check all boxes that apply to this issue:

• Bug description is provided
• Request path is provided
• Response status code is provided
• Response headers are provided
• Response body is provided
• Expected response is provided

[jowrjowr]

SSO bug.

pls refile here: https://github.com/ccpgames/sso-issues

[lukasni]

Reopening since it seems to be an error specifically with using an SSO token on ESI.

Summarizing a discussion from Slack to add relevant info:

• Access tokens with a length of 4154 (all available scopes) fail to authenticate on esi.evetech.net
• Token can be verified using https://login.eveonline.com/oauth/verify
• User specified the error does not occur when they leave out two scopes, bringing the length down to < 4096

Simple and effective workaround: Don't request tokens with all scopes.

[Blacksmoke16]

GESI requests all scopes and I haven't heard of anyone having this issue. Using the V2 SSO stuff tho.

[lukasni]

GESI requests all scopes and I haven't heard of anyone having this issue. Using the V2 SSO stuff tho.

@RamonRobben is also using V2, otherwise the scope list wouldn't affect the token length anyways. Is GESI requesting publicData and esi-corporations.read_outposts.v1, too? Guessing you might not be requesting those since they are pointless.

[BitSec01]

Then the issue seems easy to fix. Just remove publicData and esi-corporations.read_outposts.v1 from the scope list.

p.s by removing it from the scope list I mean whoever is developing this API should remove them from even being an option to select for your application.

[Blacksmoke16]

I just looked. Yea, those are the only 2 its not requesting since they're not used on any route. So that would prob be why this error doesn't happen.

But yea, prob can be removed from the dev app UI at this point.

[lukasni]

publicData does have a reason to exist and can't be removed. There's just no point in including it if you have any other scopes. It exists so people can get a refresh token for character verification without requesting any private scopes.

[ghost]

The outpost scope should def be gone though, that's an oversight. It doesn't solve the underlying problem with token length though.

[GENiALi]

I have the same problem. Everything works fine with fewer scopes, but not with all scopes.
EVE SSO/ESI verify with Angular/TypeScript

[lukasni]

@GENiALi same recommendation for you until this gets fixed, don't request the publicData and esi-corporations.read_outposts.v1 scopes since they don't serve any purpose in your request.

[ghost]

I've hidden the read_outposts and write_structures scopes because they're no longer used. At some point in the future, probably about 9 months from now, I'll for-reals delete them.

I'll put a blog out about it in a few weeks once I've spoken to the sso guys and know exactly what the plan is, but in the mean time if you guys wanna get out ahead of this, stop adding those scopes to your login URLs now and the transition should be seamless for you.

This doesn't solve the underlying problem of a token length limit, just a bit of cleanup.

[akazakou]

Confirm that still actual

[CarbonAlabel]

Updated list of useless scopes:

• publicData - v2 SSO will always provide a refresh token
• esi-characterstats.read.v1 - endpoint was recently removed
• esi-characters.read_chat_channels.v1 - endpoint was removed a long time ago
• esi-bookmarks.read_character_bookmarks.v1 and esi-bookmarks.read_corporation_bookmarks.v1 - endpoints weren't updated to the new bookmark system
• esi-wallet.read_corporation_wallet.v1 - typoed scope still available when creating an SSO app, proper scope is esi-wallet.read_corporation_wallets.v1

[mateuszkrasucki]

Internal issues: EO-13248, EO-13249

[Blacksmoke16]

ccpgames/sso-issues#63 might be related.

[noxamos]

The issue is still happening as of today. This post just saved me after hours of work trying to figure out what was wrong

[Rakdos8]

All of my token went invalid today with the error message : authentication failure
Starting at 2021-12-30 11:08:19 to 2021-12-30 11:47:15 (UTC) and probably beyond

[sergey-program]

Confirm that still actual

[clanofartisans]

I'm running into this issue as well.

[zboyet]

Wasted a good chunk of time figuring out what was going on until I stumbled upon this

[antihax]

For all running into this issue, see the workaround. You should only request the scopes you need and not everything and the kitchen sink. You can always expand upon later as you add features.

[kwladyka]

the bug still exist

[wfjsw]

This happens again. Could CCP please stop putting more thing into the token without fixing this issue? I'm leaning towards an edge where there is no spare scope for me to remove.

[Dusty-Meg]

Don't request all scopes in one token.
A lot of the scopes are barely used and can just be split out to multiple tokens.

[guiguilechat]

Yeah, you should only request the scopes you are likely to use.
Even when requesting all the usable scopes there is no problem AFAIK.

[wfjsw]

Yeah, you should only request the scopes you are likely to use.

I generally use all of them, in batches.

Even when requesting all the usable scopes there is no problem AFAIK.

I figured out it works in most cases, but not in the cases when character length is excessively long.

I do agree it should be splited to multiple tokens, but the current architecture limits me from doing so.

[guiguilechat]

I have several "dev keys" which are bascally the same, but with different scopes.
When a batch needs a key, it resolves the existing keys for that used with the required scope.
this allows users to only provide scopes they accept to.