Capture User Access Token Locally - Unity/C#

I am using user access tokens to gain access to PubSub for “bits:read” events, and though this may seem picky but is there a way to capture user access tokens for the client without them having to copy and paste a code into the application or without relying on a website/server relationship in order to manage the URI? I understand the way the API structure is basically screaming “USE A SERVER” but for those that would like to distribute applications that are server-less, client-side applications only, is there a way?

I have tried using Twitch CLI and manipulating the CLI through the application, I have gotten to the point of accessing the token, but there is no way to transfer the token from CLI back to application, nor is there a way to serialize the information from the CLI into a file that can be accessed by the program. (I have tried using the “>” method with command prompt)

I am assuming there is a way, but I am curious if I am missing something.

You would take the model of the CLI, start a temporary web server to capture the response.

Alternatively you use a Server or a webpage to handle the oAuth loop which then forwards the token to a customURI handler or some other way to relay to Unity.

The third alternative is an accounts system the user logs into your game using your accounts system, then on your accounts system you have a “link my Twitch account”. You’d need this approach if you were going to do drops for example.

The other alternative for bits:read is that you could connect to chat anonomously (using the justinfan login method, justfinfanX where X is a number and a no or a blank password) and then parse chat for bits/cheer events. So then you only need to ask the streamer for their channel name (and convert to lower case)

Thank you for the quick response!
A few concerns…

“use a Server or webpage to handle oAuth loop” still means I have to use a server, which I am trying to avoid, unless you are implying that I write code for a localhost server to capture callbacks. In which case, I’ve considered it, but it’s really an issue of overcomplicating a solution.

accounts system” is implying a persistence method? But doesn’t necessarily tackle the main issue of bypassing a server hosted callback URI management system. Unless, the accounts system you are mentioning is managed by Twitch, in which case I am unfamiliar.

Parsing chat through IRC was my first idea, though, I would prefer to use PubSub to take advantage of websockets, get accurate data without error in parsing, and bypass the need to read every message looking for a cheer.

Lastly, take a model of the CLI? Assuming you mean to model some code after the CLI to manage the issue myself? In which case, the answer is presumably similar to the “use a Server or webpage” option, which goes back to the overcomplicating the solution thing. Or maybe fork the CLI repo and edit it to fit my needs? Which I also considered, but not sure about the legalities of distributing the CLI through a paid application. Though, if I am 100% honest, I am not sure what you mean by this option.

Again, thanks for the response! Seemingly there isn’t a built in solution, which I kind of expected, though I am thankful for your help!

By server I mean start a temporary web server inside the game

A custom accounts system for your own game. Your can connects to your extenal accounts system on a public server (which you are trying to avoid having) and fetchs the linked twitch account access token and uses that.

The CLI starts a temporary web sever to capture oAuth codes for exchange for tokens

I was suggesting you could copy the proceedure not the code itself.


The primary ways to get a token into a game are

  • user copy pastes the token
  • you start a temporary web server to handle the oAuth steps
  • you run a server external to the game on the web to handle oAuth and pass the token into the game somehow (Theres a variety of methods that can work)

Ah, ok. So, really its either the overcomplicated method, or a method I am trying to avoid. That explains things.

Again, thanks for your time!

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