API Breaking Change: Denying requests with expired OAuth Access Tokens




Starting today (May 9th 2018), our API is starting to deny requests made with expired OAuth Access Tokens.

Since a bug was inadvertently introduced in February 2017, it has been quietly accepting expired access tokens. We have just deployed a change that will deny requests made to our expired with expired tokens.

A few weeks ago, we sent an email to the owners of registered applications found to be making API requests with expired tokens, privately disclosing the issue and instructing them to fix their application and use the documented refresh token mechanism instead, in accordance with responsible disclosure security practices.

If you’re the maintainer of an application using the Envato OAuth API, your application will only be impacted if it is still making calls with expired stored OAuth access tokens, in which case you should have received an email with instructions about how to address it. If you haven’t yet, you may start noticing those requests now result in an error, and you’ll want to implement the refresh token mechanism to fix it (more below).

For the rest of our community, there is no action to take, though you may start noticing errors in the third-party applications you are using that depend on our OAuth (like author support platforms)

What’s an OAuth Access Token?

OAuth clients (third-party apps) ask the user to authorize them to make calls to the Envato API on their behalf by sending them to the OAuth authorization form. When the user approves the form, the third-party application gets an authorization code that it can exchange against an Access Token and a Refresh Token with our API.

The Access Token can be used by the application to make API requests on behalf of the user. It can use it to query the API as if it was the user, and access information about their account, like their username, or the list of items they purchased that were made by the application’s authors to verify purchases. What they have access to is limited by the list of permissions shown to the user in the Authorization form.

The Access Token is supposed to have a short TTL (Time To Live, or time after which the token expires) of 1 hour. After that, if the third-party app needs to make more requests to the Envato API on behalf of the user, they need to use the Refresh Token to ask our API for a new Access Token. The Refresh Token doesn’t expire.

That’s a security feature of the OAuth protocol so that if an Access Token gets compromised it can’t be used for long. It’s like a browser session that expires after some time and you need to sign in again.

Please note OAuth Access Tokens are not the same as Personal Tokens, that don’t expire and won’t be affected by this.

So what was wrong?

After we migrated the backend of our API Gateway in February 2017, we accidentally dropped the verification step on the Access Token TTL.

And what is changing?

We are now reinstating the TTL check so the API won’t accept expired tokens and will deny requests made with expired API tokens.

Is this an exploitable vulnerability?

Not really. Access tokens are obtained under the same conditions as the Refresh Token, and if the third-party app uses and stores them securely, there’s no reason for them to be compromised. Still, it is safer to expire them after a while, which is why OAuth has this feature and we should have been enforcing it.

What should maintainers of OAuth applications do?

As of now (May 9th 2018), your application will get a “Deny” response when making requests to our API with an expired OAuth access token. Hopefully, you will have built your application to avoid making requests with expired tokens, in accordance with our documentation, or have fixed it after receiving our email, and your application won’t be impacted by this change.

If you haven’t, the actions where your application makes requests to our API with expired tokens are likely to be impaired.

If you maintain an application that makes requests to the API with stored OAuth Access Tokens, we recommend you implement the documented Refresh Token mechanism to get a fresh token when needed before making a new request:

  • when the app gets its first Access Token for a given user via the /token endpoint, store the TTL, the Refresh Token (securely) and issue time (current time then)
  • when making an API request with a stored Access Token, first check if the Access Token is outdated (if current time > last issue time + ttl), and if so get a new token with a call to /token passing the Refresh Token as a parameter

If you haven’t stored the Refresh Token for the Access Tokens your application currently holds, you will have to ask the users to go through the OAuth authorization form again, so your application can get an authorization code that will let it get a new Access/Refresh Token pair.

What should users of Envato OAuth applications do?

You don’t need to do anything. Just note that some features of some of those applications may stop working or their data may fail to stay up-to-date as a result of this, until the maintainer fixes the problem.

In some cases, you may be able to fix the issue temporarily by going through the OAuth authorization form again (via the “sign in” link you first used to sign up to the app and grant it access to your account in the first place). That will automatically trigger a new authorization event, that should let the application get a new Access Token for your account.

Once the maintainer has upgraded their application to use the refresh mechanism, you may need to sign in to the app again through the OAuth authorization form again


Is this the message that you are returning when the access token is expired?
" User is not authorized to access this resource with an explicit deny"?


Now, after new changes, received a new Access Token obtained by the Refresh Token initially not working


Yes, That’s what it output when using an expired token


I have tested it and it’s working fine


Is this the message that you are returning when the access token is expired?
" User is not authorized to access this resource with an explicit deny"?

Yes, that’s the one.

Please note it’s actually the same message as when you use an incorrect token.

Unfortunately, the underlying technology we’re using for our API Gateway leaves us with no easy way to customize the error message returned for different types of denial by the Gateway (e.g. expired token vs wrong token altogether). Sorry about that.


Hi guys,

Just want to clear one thing. If we didn’t refreshed the access token before you made this change, the client will have to redo the authentification process?

I am asking because we have an app in which we haven’t made the proper changes and now, when we try to get a new access token using the refresh token we have stored we get a “User is not authorized to access this resource with an explicit deny” message.

Thank you,


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.