-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Token expiry is too far in the future #66
Comments
Looks like this behaviour is back, I've been getting pings from my services that tokens expiry is too far in the future. |
Also getting this but in json form {"error":"token expiry is too far in the future","sso_status":200} |
Can confirm, getting it as well ... |
Who is returning that response? Where is the token being sent? |
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:
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. |
Can you give us an example of a client_ID that shows this behaviour? |
Sure, this is the client_id I'm using: |
And are you using |
I am using |
This behaviour is back again. From my logging:
|
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 |
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
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.
The text was updated successfully, but these errors were encountered: