Token expiry is too far in the future

[warlof]

Bug

Reproduction Steps

Renew an SSO v2 token

Actual Behaviour

Newly delivered token is shipped with an expiry time far away (somewhere in april 2021). If the token seems to be valid, backend is bouncing it, due to some extra controls based on the expiration date/time.

When such case appears, requests using this token are denied with http status 403 and the following message

token expiry is too far in the future

This situation has already be seen in the past, however, the last 48 hours, its occurrence explode and impact a lot of people.

A workaround is to force the token to be renewed manually. However, this is not a normal workflow.

Expected Behaviour

Either backend shouldn't bounce the provided token which is valid. Or delivered token shouldn't be shipped with a non trusted expiration date/time.

[Cwittofur]

Looks like this behaviour is back, I've been getting pings from my services that tokens expiry is too far in the future.

[irwiss]

Also getting this but in json form

{"error":"token expiry is too far in the future","sso_status":200}

[ppfeufer]

Can confirm, getting it as well ...

[stebet]

Who is returning that response? Where is the token being sent?

[Cwittofur]

When we request a token from CCP using their oauth api we are receiving a valid token, however when you analyze the token in a token viewer (jwt.io) you'll notice the expiry is set for some time in May. Because of this, whenever we use those tokens to perform an API call we receive the error that was listed above:

{"error":"token expiry is too far in the future","sso_status":200}

The issue arose late last year, around when the issue was initially opened. All was fine for a bit, but the issue has since reappeared.

I have refreshed tokens manually and I'm still receiving the incorrect expiry. There is not a whole lot the consumers can do on this part, we'll need the token provider (CCP) to identify the cause of the issue and provide a fix.

[stebet]

Can you give us an example of a client_ID that shows this behaviour?

[Cwittofur]

Sure, this is the client_id I'm using: e62ced8e30454c66b7cdabde2034c3cc

[stebet]

And are you using oauth/token or v2/oauth/token to refresh tokens?

[Cwittofur]

I am using v2/oauth/token

[PrometheusSatyen]

This behaviour is back again.

From my logging:

ESI Request #138397
GET /v5/characters/[REDACTED]/notifications
2021-06-19T19:20:01.509Z
Request Query:
{}

Response Status: 403
Response Body:

{"error":"token expiry is too far in the future","sso_status":200}

[1adog1]

I recently noticed this behavior in one of my apps, but I'm not sure exactly when it occurred (only that it was on or prior to April 16th, 2023). 9 refresh tokens returned access tokens that had iat and exp fields set to May 31st, 2023. The difference between the values was the correct 1200 seconds, and all tokens had iat timestamps within about a half hour (several within seconds) of eachother. I still have 7 of the access tokens on file in case that'd be of help.