IRC bot now needs an OAuth for Helix API calls

I’m developing an IRC bot and I decided to add support for Twitch chat. Within the confines of TMI/IRC, everything works fine, provided the user supplies an OAuth to log in.

Inspired by other popular bots I eventually started looking into using the API for richer commands, concretely !followage. I registered the application and got a client ID, and got it working (although it’s still very much a work in progress). But then Requiring OAuth for Helix Twitch API Endpoints happened and now the ID isn’t enough.

TL;DR: Where do I get an OAuth key to authorize simple queries? The one used to log onto IRC did not seem to be it.

I intend to let anyone download the source, compile it and run the bot as they please.

The only way I found to achieve this was to generate a client ID, generate a client secret, then use both to request an authorization token from with grant_type “client_credentials”. With the returned authorization token as Bearer, everything works.

But the docs page on getting oauth keys says client_credentials should be requested “only as a server-to-server request, never in client code”. Additionally, it would mean that every user would have to each separately register the same application for a unique client ID to get the client secret, and ultimately an oauth that still expires in 60 days.

I only need enough to let the client query public information like, and the such. I’m fine with refreshing tokens, but I can’t just hardcode a secret into the program.

I’m probably missing something. Is there an easier, less roundabout way?

On GitHub:

You would use implicit flow if the bot is only client side. The user would log into the bot directly then use that token for both chat login and api calls.

Thank you for your reply. I can’t get implicit flow to work, though.

Following the steps in the Getting Tokens docs, something as easy as copying the example 1:1 and replacing the client key:

$ curl -X GET “${CLIENT_ID}&redirect_uri=http://localhost&scope=viewing_activity_read&state=c3ab8aa609ea11e793ae92361f002671&force_verify=true

…admittedly does give me an HTML link…

<a href=“${CLIENT_ID}&redirect_params=client_id%3D${CLIENT_ID}%26force_verify%3Dtrue%26redirect_uri%3Dhttp%3A%2F%2Flocalhost%26response_type%3Dtoken%26scope%3Dviewing_activity_read%26state%3Dc3ab8aa609ea11e793ae92361f002671”>Found</a>.

…but it just leads me to the Twitch front page ( Authentication is only requested if I log out first, and even then it doesn’t redirect me to the http://localhost redirect URL; it stays on the front page, and that’s with force_verify=true.

It seems like implicit flow is the right way to go. What am I doing wrong when I can’t even get the example working?

You need to redirect the user there, not use curl or any HTTP request library or otherwise you’ll just get back HTML which wont work. You have to send the user to that link.

Initial tests shows that worked, I’ll know for sure the next window. Cheers!

Will this access token last 60 days and then require manual refreshing with the user opening a browser again? I didn’t see any expires_in in the fragment identifiers.

Yes, the token will expire after roughly 60 days and they’ll have to go through the process again, although if you remove force_verify=true from the url, the user will only be asked to grant your app permissions the first time they go through it, from then on they will instantly be sent back to your redirect url with a token (unless they have disconnected your app from their Twitch account).

The validation endpoint should return the expires_in value

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