Expired Access Token in /userinfo request [auth0-java]

SDKs/Libraries
, , ,
#1

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?

#3

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.

#4

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.

#5

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?

#6

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.

#7

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.)

#8

Closing after >2 weeks inactivity.

#9