Public Client ID Stopped Working

API
1

I’ve been using the same Client ID for my application for a couple of months. This is Public type client that I control. I’ve been using it to make API calls such as retrieving a user and logging into chat via IRC. A couple days ago IRC login started returning “Login authentication failed”. Retrieving users now returns no results.

I started seeing this behavior at the same time on two different machines, each with their own OAuth access token. Both represent my user which has no issues accessing Twitch. Another user of my tool reports it’s not talking to Twitch chat. I’ve tried getting a new OAuth token for my user from the same Client ID; the token gets issued successfully but API/chat access doesn’t work from that new token.

The timing comes shortly after I made the repo with my code and client ID public. I think this may be a case of a scraper discovering the client ID and abusing it but I have no evidence of this. There’s nothing special showing in the dev dashboard for my application.

What can I do to troubleshoot this?

2

I created a new application with the same configuration (public client). I loaded the client ID in my program, generated a new oauth token for my user and everything works. I think this suggests the issue is with the existing client ID. If this is the case, it would be really nice if there was a way to discover this other than trial and error.

3

So the oAuth token generated died?

Use validate to confirm - Validating Tokens | Twitch Developers

So the oAuth token doesn’t have the required scopes on it?

Use validate to check what scopes are on a token - Validating Tokens | Twitch Developers

Sounds like you actually made the oAuth token public instead in your repo? And someone revoked the token.

ClientID’s are public since they form part of the URL to authenticate with.

If that was the case then you wouldn’t be able to generate oAuth tokens, you wouldn’t just not be able to connect to chat

4

@BarryCarlyon I appreciate your fast and thorough response.

I’m now pretty confident my issue is purely token expiration. The tokens failing at the same time is probably coincidence of them being issued at about the same time with the software first supporting Twitch integration.

I didn’t realize that tokens issued through the implicit grant flow expire. The documentation of the response on issuance doesn’t include a refresh token or an expiration. The documentation for the implicit grant flow doesn’t mention expiration at all:

http://localhost:3000/
    #access_token=73d0f8mkabpbmjp921asv2jaidwxn
    &scope=channel%3Amanage%3Apolls+channel%3Aread%3Apolls
    &state=c3ab8aa609ea11e793ae92361f002671
    &token_type=bearer

The page on Refreshing Access Tokens states:

The lifetime of an access token depends on how you acquired the token. When you get a token, the expires_in field indicates how long, in seconds, the token is valid for.

Since there’s no expires_in in the implicit flow response, it’s pretty unclear.

I think the documentation could be improved here.

Now I need to figure out why I wasn’t getting an Unauthorized back from my library with expired tokens :expressionless:

5

It’s right here: Authentication | Twitch Developers

Tokens don’t last forever

Access and refresh tokens can become invalid for the following reasons:

Not required by the standard on implict auth so it doesn’t, it’s generally expected with such a token/oAuth method, that you’ll end the users session, and get a new token, before the token itself dies

Stadand documentation: RFC 6749 - The OAuth 2.0 Authorization Framework

expires_in is just RECOMMENDED but not REQUIRED

Since

If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.

Via the validation endpoint Validating Tokens | Twitch Developers

Implict tokens cannot be refreshed.

You can only get a new one.

6

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