Creating token from stored and "expired" serialized Token results in JWT Exception.

[Dwarfex]

Hi,

i store the obtained token within the session and check from time to time if it is still valid or if i need to refresh the token.

In the scenario that a user stays idle until the token is expired i noticed following behavior:

I deserialize the stored token and try to create a new instance of the token. $token = new AccessToken($expiredTokenOptionsFromSession, $this->provider)

My intention was to to use $token->hasExpired() and if it is expired to call: $grant = new RefreshToken(); $newAccessToken = $this->provider->getAccessToken($grant, ['refresh_token' => $token->getRefreshToken()]);

Unfortunately new AccessToken($expiredTokenOptionsFromSession, $this->provider) fails with an Exception from firebase/php-jwt "new ExpiredException('Expired token')".

So i had to find a workaround for this - which is basically checking the expiredTokenOptionsFromSession for expiration and avoiding the creation of a AccessToken instance.

This issue is already now and discussed by php-jwt (https://github.com/firebase/php-jwt/issues/291).

I would expect my intention to work - or am i mistaken here?

Greetings, Dwarfex

[hajekj]

I simply store the entire response form getAccessToken in the $_SESSION and then use it which seems to work fine.

Sample: https://github.com/TheNetworg/DreamSpark-SSO/blob/master/includes/app.oauth2.php#L42

[Dwarfex]

So you mean instead of de-/ serializing the Token and storing the serialized data, you directly store the object in the session.

Wich - yeah - is a workaround for instantiating a new object with the expired data - good point. This might be a bit more elegant than my extra steps.

Nevertheless i don't think it is very intuitive?

P.S. awesome fast response!

[hajekj]

You shouldn't store the token outside the scope. Yeah, I need to work on the documentation more.

[Dwarfex]

Yeah okay - thanks for the clarification.