Channel points have the ability to reward loyal viewers with real-time influence on the stream. Sometimes such requests may be filtered, which should trigger a rejection (therefore refund).

Right now the only way to do this programmatically would be to use unsupported GQL APIs and risk the wrath of Twitch, or wrap the rewards queue in some way. This is the only blocker (technically speaking) for the workflow, as PubSub does expose enough information to respond to the redemptions automatically.

I've had a proof of concept on my stream which gets redemptions via PubSub, filters the submission for offensive content via an API, and changes some text elements on my stream layout automatically. It's been well-received by my (tiny) viewership but it would never really scale without these APIs.

Perhaps worth noting that there's a practical workaround that takes the bulk of the interaction out of Twitch: channel points rewards could be configured which are not queued, and are processed (via PubSub) automatically by a bot to turn into bot points - and then the bot points spent as prices on bot commands.

The Get Clips API should include information of all deleted clips matching the current clips request too when used with a proposed deleted=true parameter. Limited to only the broadcaster themselves and maybe behind some appropriate scope too.

Goal: detecting malicious, weird and creepy clipping behavior from people making clips, downloading them, and instantly deleting them which is a very common pattern that's currently almost impossible to detect for streamers.

Sometimes streamers will accidentally show something they didn't mean to for a second, or say something that can be taken out of context, and some people are just weird and clip certain normal actions of a streamer over and over again.

It has turned out to be a very common pattern for some malicious viewers to clip those things and then immediately delete the clips after downloading the file locally to be able to save clips of it without the streamer or mods ever being aware of it.

Having made a custom tool to automatically constantly monitor new clips (including clip deletions) of some channels I moderate has enabled identifying many viewers showing clearly malicious, weird, creepy and generally bannable and reportable behavior that would otherwise have been gone completely unnoticed to the streamer and mods without such a tool.

This appears to happen on almost any remotely big channel however generally goes completely unnoticed as it is almost undetectable without such a monitoring tool.

Examples include instances of people making literally dozens of clips of a streamer getting up from their chair, or stretching, or many people clipping when a streamer accidentally leaks some info on stream for a second, and then all deleting the clips instantly.

With the current Clips API limitations it's nearly impossible to make such a tracking tool reliable, and it requires a lot of unnecessarily frequent API calls to even get moderately good coverage. This would all not be necessary in the first place if broadcasters were be able retrieve all info of deleted clips from their channels and is essential to identifying malicious clipping behavior and should be available to the broadcaster.

The "This extension can view my subscriptions list." toggle, (in Manage Extension Permissions) doesn't do a check to see if the channel that the extension is installed upon, is eligible for Subscriptions at all.

Wording should/could be changed to prevent broadcasters of type BLANK (as apposed to affiliate/partner), becoming confused.

As they'll click the toggle, run the oAuth dialog and then the toggle is still off.

On hitting the toggle, change the popup response from:

> "You have successfully authorized this extension to view your subscriber list!"

To

> "You have successfully authorized this extension to view your subscriber list! But you don't have subscribers so when if you become an affiliate we are good to go"

And/or change the wording on the toggle to indicate that the channel is not enrolled in the subscribers platform

Imagine the following attack for the OAuth 2.0 authorization flow:

1. Attacker steals the authorization code from the redirect URI.


2. Attacker forces his instance of the client to redeem the victim's authorization code.


3. If the attacker's instance of the client is faster than the victim's instance of the client in redeeming the authorization code, the attacker will get a valid login session within his instance of the client, but for the victim's account.

This attack should especially get attention in the context of Twitch and live streaming, since many streamers are definitely not aware of this vulnerability: If people are logging in with Twitch on 3rd party sites while live streaming, an attacker that has automated this attacking process (e.g. by capturing the stream) can easily grab the authorization code from the visible browser address bar during the streamer's login attempt, except ...

... the OAuth 2.0 PKCE extension is used by the client, which prevents the attack in the following way:

1. A hashed secret (using a cryptographic hash function) is send using the nonce parameter of the initial authorization request (leading to the Twitch login page).


2. Later, the authorization server (that is used to redeem authorization codes) is sending back the same nonce together with the access token.

The back end implementation (that also securely stores the client secret and makes the call to this authorization server) can now verify whether the nonce sent back from the authorization server is indeed the hashed value of the specific secret.
An attacker that does not know the secret should now longer be able to force the back end to authorize him with the victim's permissions.
Of course, the secret is bound to the authentication session and only visible to an attacker in its hashed form (the nonce) within the initial authentication request.

A few months ago someone suggested to support the OAuth 2.0 authroization flow PKCE extension. [1]
I don't know if the nonce usage above is exactly the same as PKCE, but it at least prevents attack scenarios like the one that I just described.

Currently, the documentation does not mention this nonce parameter being available for the OAuth 2.0 authorization flow. [2] It should be added with a short description, similar to the other optional parameters like state or force_verify to make people aware of it.

This user voice is a clone of this thread in the forum. [3]

[1] https://discuss.dev.twitch.tv/t/pkce-extension-for-oauth-authorization-code-flow/19575
[2] https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#oauth-authorization-code-flow
[3] https://discuss.dev.twitch.tv/t/please-document-optional-oauth-2-0-authorization-flow-parameter-nonce/23357