Refreshing OAuth 2 access tokens because a HTTP 401?

[Dave Shawley]

I could not find a reference as to when I should refresh an OAuth 2 access token outside of the expiration hint.  As far as I can tell the v3 APIs return a 401 with an invalid_token error which is what I would expect based on RFC-6750 [1].  However, the same "error" is returned when the client ID is incorrect or the token is malformed.  The only difference that I can see is in the "error_description" field.

Should my application be refreshing the access token when it receives a 401 with a JSON response body where "error=invalid_token" and "error_description" contains the word expired?

When I make a request with an expired access token, I receive a 401 response with the following body::

    {"error": "invalid_token", "error_description": "access token is expired"}

If I make the same request with a malformed token, I receive a 401 response with the following body:

    {"error": "invalid_token", "error_description": "access token is invalid"}

If I make the same request with a garbage value in the "x-api-key" header, I receive a 401 response with the following body:

    {"error": "Invalid API key"}

I want to avoid making access token refresh attempts where they cannot possibly succeed.  I believe that looking at the error description is the only way to do this today.  Is this documented anywhere?

[1]: https://datatracker.ietf.org/doc/html/rfc6750#section-3.1

Dave Shawley

AWeber Integrations Technical Lead

Pronouns: he, his, him | Communication Pref: written, async

Send smarter emails based on open and click tags. AWeber Automations is here. 

…And We’re Hiring!

[david olick]

When you first receive an access token, you should immediately request a refresh token.

Store the refresh token, as it's valid for ~90 days.  Whenever you want to use the API again, use the refresh token to create a new access token, which will last for ~1 hour.

--
You received this message because you are subscribed to the Google Groups "Etsy API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to etsy-api-v2...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/etsy-api-v2/a836cb48-2a78-4110-acf4-216c34c81f40n%40googlegroups.com.

[david olick]

One more thing:  When you use the refresh token to request a new access token... Etsy sends you a brand new refresh token.  Replace your old refresh token with the new one, as that one has a new lifespan of ~90 days.

[Dave Shawley]

That is what I was thinking initially.  Then it occurred to me that a long running process (or browser window for that matter) could end up trying to use an expired token and get  401 "expired token" response.  It lead me to implement token refreshing in a wrapper that calls the Etsy API.  If it detects the need to refresh the token, then it refreshes it and reissues the request.  The result made the need to refresh the token transparent.  However, I need to be able to safely detect when a token has expired separately from revocation or some other failure.  As far as I can tell, the only way to do this today is by looking at the `error_description`.

I am saving the access/refresh token pair whenever I need to refresh the token.  That is a very important thing with this particular OAuth 2 implementation.

[david olick]

Ah, I see what you are saying now.  In API v2 it would have different error strings for different errors (token_revoked, etc).  In API v3, it has the same error string for different errors.

I think the current solution is to do what you said and look at error_description.  It would be nice if you didn't have to parse what appears to be a non-standardized error field that may change in the future.

I hope an Etsy developer chimes in and can either assure us that error_description will never change or offer a solution that we can depend on not changing.

To view this discussion on the web visit https://groups.google.com/d/msgid/etsy-api-v2/ab07a010-e4e8-4c5a-a85c-2cfe2328a523n%40googlegroups.com.

[Dave Shawley]

I posted a feature request in github.com/etsy/open-api to see if the API could be modified to clear up the ambiguous responses. #fingers-crossed

https://github.com/etsy/open-api/issues/370