Solved: Re: Access token issued timestamp changes with DST

srinivasgog · 11-08-2021 03:00 PM

Access tokens issued to the client at 2: 00 AM not working when time zone (DST) changed back to 1:00 AM. Token works fine as soon as time moves to 2:00 AM. What is the apigee internal time zone? how it differential DST times? How to fill this gap. @dchiesa1 @anilsr

dchiesa1

Have you reproduced this? Can you reproduce it?

We have o(1000) customers and almost all of them use OAuth tokens. And we go through timezone changes several times per year for many of them. And we've never heard a report like this, in the ~9 years I've been working with Apigee, as far as I know. It would be extraordinary if your observation was a result of a systemic problem within Apigee. It would be extraordinary because no one else has reported such a problem, and lots of other customers use OAuth and deal with time changes.

If the problem is limited to your system and your client app, then.... it suggests the source of the problem is there.... not in Apigee.

You may wish to prefer to diagnose this with the help of the Apigee support team. They'll be able to look at your system logs directly to help you diagnose. I can't do that. I can only look at the things you post here.

got “Token expired” errors which got resolved at 2.00AM EST without any changes.

I understand you had errors that "got resolved", but to diagnose this, you'd need to consider much more detail about the specific token that was being treated as expired, and what "got resolved" means. is it the case that the app refreshed the token, and then the "token expired" error stopped occurring with the new access token? If that's the case, one possible explanation is: (1) the original token was actually expired and the "token expired" message was correct, (2) the client app was performing time arithmetic to decide when to refresh its token, and (3) the arithmetic on the client side was incorrect, so it was trying to use a stale token. That would explain what you saw. On the other hand, if the app presented literally the same token, and at time t1 the response was "token expired" and at time t2 (after t1) it was treated as valid, then that indicates something else, a different puzzle. I find this much harder to believe, so we'd need some test case to reproduce this.

Was this a JWT or an opaque OAuth token?

If it's a JWT, there is a "nbf" field that applies, which means "not before". And it's possible your token issuer, if it has a bug, might have used a nbf value that was ... in the future. In that case you wouldn't get "token expired" but you would get "token not yet valid." That's not what you described though. I'm just trying to imagine what possible circumstance could lead to the observation you're reporting.

How many tokens were involved? One? 1000? a million? Is the problem still happening?

If this is a one-time thing, and it occurred only around the moment of time-change for daylight savings, and ONLY FOR YOU, or only for A SPECIFIC APP, then I would first look into the client app that is managing the refresh of tokens. Arithmetic around time changes is tricky.

A best practice is to design the client side app to handle a 401 response code (or whatever your API returns on expired token) by requesting a new token (grant_type=refresh_token or similar) and retrying the API call. If you build the client logic that way then there is no way to get tripped up by the time change.This is not always possible, but it's an idea to consider.

sorry I don't have firm answers for you, but these are things you can explore to help you diagnose.

View solution in original post

dchiesa1

Can you explain in more detail, like serious over-explaining detail, what you mean by

Access tokens issued to the client at 2: 00 AM not working when time zone (DST) changed back to 1:00 AM.

Which time zone, which system had its timezone change, how did you change it, how did you observe this? Have you reproduced this? etc etc.

Apigee doesn't use a timezone on its servers. It uses UTC.

I'll be interested to hear what you tested, how you tested the behavior you're describing.

srinivasgog

@dchiesa1 We're in EST, consumer application generated token at 1.00 AM EST while trying to connect to API through APIGEE (OAuth policy) got “Token expired” errors which got resolved at 2.00AM EST without any changes. On edge analytics shows the errors with in same time.

dchiesa1

Have you reproduced this? Can you reproduce it?

We have o(1000) customers and almost all of them use OAuth tokens. And we go through timezone changes several times per year for many of them. And we've never heard a report like this, in the ~9 years I've been working with Apigee, as far as I know. It would be extraordinary if your observation was a result of a systemic problem within Apigee. It would be extraordinary because no one else has reported such a problem, and lots of other customers use OAuth and deal with time changes.

If the problem is limited to your system and your client app, then.... it suggests the source of the problem is there.... not in Apigee.

You may wish to prefer to diagnose this with the help of the Apigee support team. They'll be able to look at your system logs directly to help you diagnose. I can't do that. I can only look at the things you post here.

got “Token expired” errors which got resolved at 2.00AM EST without any changes.

I understand you had errors that "got resolved", but to diagnose this, you'd need to consider much more detail about the specific token that was being treated as expired, and what "got resolved" means. is it the case that the app refreshed the token, and then the "token expired" error stopped occurring with the new access token? If that's the case, one possible explanation is: (1) the original token was actually expired and the "token expired" message was correct, (2) the client app was performing time arithmetic to decide when to refresh its token, and (3) the arithmetic on the client side was incorrect, so it was trying to use a stale token. That would explain what you saw. On the other hand, if the app presented literally the same token, and at time t1 the response was "token expired" and at time t2 (after t1) it was treated as valid, then that indicates something else, a different puzzle. I find this much harder to believe, so we'd need some test case to reproduce this.

Was this a JWT or an opaque OAuth token?

If it's a JWT, there is a "nbf" field that applies, which means "not before". And it's possible your token issuer, if it has a bug, might have used a nbf value that was ... in the future. In that case you wouldn't get "token expired" but you would get "token not yet valid." That's not what you described though. I'm just trying to imagine what possible circumstance could lead to the observation you're reporting.

How many tokens were involved? One? 1000? a million? Is the problem still happening?

If this is a one-time thing, and it occurred only around the moment of time-change for daylight savings, and ONLY FOR YOU, or only for A SPECIFIC APP, then I would first look into the client app that is managing the refresh of tokens. Arithmetic around time changes is tricky.

A best practice is to design the client side app to handle a 401 response code (or whatever your API returns on expired token) by requesting a new token (grant_type=refresh_token or similar) and retrying the API call. If you build the client logic that way then there is no way to get tripped up by the time change.This is not always possible, but it's an idea to consider.

sorry I don't have firm answers for you, but these are things you can explore to help you diagnose.