401 response is missing WWW-Authenticate header on invalid bearer app access token


We’re currently updating our application to use Helix API. We use it to fetch data of public videos and streams. We use app access tokens (grant_type=client_credentials) to authorize our requests; the sole purpose of it is to get the higher rate limit associated with it (800/800 instead of 30/30).

We run into an issue regarding access token expiration. We followed the recommandations found in the doc https://dev.twitch.tv/docs/authentication/#refreshing-access-tokens, i.e.:

We recommend that you refresh your tokens in response to being rejected by the server for bad authentication.

When you make a request with expired or incorrect authorization credentials, the API returns a WWW-Authenticate header (with an invalid_token error) and a 401 Unauthorized status.

But our tests showed that we never get that “WWW-Authenticate” header in response of a request with an invalid app access token, e.g. after revoking it using https://id.twitch.tv/oauth2/revoke (for pratical reasons we weren’t able to try with natural expiration of the token, after two months). For instance a request of a public video with a revoked token without WWW-Authenticate response header:

> GET /helix/videos?id=30762991 HTTP/2
> Host: api.twitch.tv
> User-Agent: curl/7.59.0
> Accept: */*
> Authorization: Bearer <revoked_token>
< HTTP/2 401 
< content-type: application/json; charset=utf-8
< content-length: 95
< server: nginx
< access-control-allow-origin: *
< cache-control: no-cache, no-store, must-revalidate, private
< expires: 0
< pragma: no-cache
< twitch-trace-id: 0298bab4612ee0cfa64bf510c6617d72
< x-ctxlog-logid: 1-5be45923-c876869ca80ac080860bd9b2
< timing-allow-origin: https://www.twitch.tv
< date: Thu, 08 Nov 2018 15:41:23 GMT
{"error":"Unauthorized","status":401,"message":"Must provide a valid Client-ID or OAuth token"}

We think that it may be because we use client auth and not user auth or because the video is public thus doesn’t require auth. Either way it was surprising to us; perhaps the documentation about this could be improved to be more precise?

We decided to program the regeneration of the token on any 401 without checking for WWW-Authenticate header. Do you think this is OK? Any pitfall to doing this?

Thanks for your time.

1 Like

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