Please include the following information in your post:
I have a general query.
For the /userinfo API we have in the SDK AuthAPI.userInfo(accessToken).
For this, in case we use a valid but expired token (older than 24 hours), will we get a regular unauthenticated Error as we get for invalid tokens, or will we get a proper token expired exception?
If such a specific exception is not being provided by the function currently, would it be possible to get it added in a subsequent update in the SDK?
Hi @arnabroy1907dev,
Did you try sending an expired token? I can’t find a specific answer without testing it.
If you end up wanting to request it, feature requests can be made directly in the repo as an issue. here.
Hey Dan,
I did this experiment. I used a 2-3 days old access token. I’m getting a generic Unauthorized 401 error with cause as invalid_token.
I thought it might just be missing from the SDK side. However, I tried the same with the /userinfo endpoint and it threw the same Unauthorized error as well.
I guess change doesn’t have to be at the SDK level but rather at how the /userinfo endpoint works.
Hi @arnabroy1907dev,
This looks like something that is defined directly in the \Oauth2 spec here. This is what it says:
invalid_token
The access token provided is expired, revoked, malformed, or
invalid for other reasons. The resource SHOULD respond with
the HTTP 401 (Unauthorized) status code. The client MAY
request a new access token and retry the protected resource
request.
It looks like there is an option for an error_description. Are you not seeing that?
Hey Dan,
Sure I can see the error description. It shows:
"The access token signature could not be validated. A common cause of this is requesting multiple audiences for an access token signed with HS256, as that signature scheme requires only a single recipient for its security. Please change your API to employ RS256 if you wish to have multiple audiences for your access tokens"
However, putting both revoked/malformed token error and expired token error seems a little wrong.
The use case that I’m thinking of is when we have a bad token or a malformed token we would want to send an unauthorized error. However, if the token is expired, we would want to use the refresh token to generate a new access token.
Generating a new access token using refresh token for all 401 invalid_token errors is wrong in my opinion. We shouldn’t generate a new token if the access_token provided is incorrect. We should only generate if the token is correct but expired.
Can you instead look at the expiration time instead of sending the expired token? I think our SDKs will do this automatically. (maybe not with the Java SDK.)
Closing after >2 weeks inactivity.