I think it has something to do with the length of the access_token, because authorization through an application with fewer permissions gives a positive answer.
OMG I’ve been bashing my head against a very hard brick wall on this too…
I have a OAuth2 flow coded up in my web app, and am having issues reading authenticated endpoints.
I’ve followed the guide here OAuth 2.0 for Web Based Applications | esi-docs
And get back an access_token, and I successfully use that token to verify the user:
ACCESS_TOKEN=eyJhbGciOiJ... # 4136 charectors long!
curl 'https://login.eveonline.com/oauth/verify' --header "Authorization: Bearer $ACCESS_TOKEN" | jq
{
"CharacterID": 2116553599,
...
"Scopes": "... esi-industry.read_character_jobs.v1 ..." # all the available scopes!
...
}
But then attempting to use that same token to get some authenticated API call, it returns error 403 :
Your point on Swagger usage was interesting, but I could not reproduce this.
Authorising on there with all the scopes, gives me a access_token that both works on their Swagger UI and on the command line example above.
But I did prove the inverse, that from my application if I requested less scopes, it created a shorter (879 characters) access_token, that does also work on the command line above.
So just need to find the breaking point, and hope I don’t need more scopes than that!