If I have an oAuth that represents a User, where the User is either

• the broadcaster the clip is of


• an editor of the channel that the clip is of


• the user is the owner of the clip

And I make a request for a Clip as documented: https://dev.twitch.tv/docs/api/reference#get-clips

(but with the bearer naturally)

The JSON Response should include the direct link to the MP4 or an ability to download the Clip.

This is off the back of the removal/deprecation of some undocumented API's that I was using to get the MP4 URL for automated download for creation of clip reels and similar.

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

The New Twitch API needs serious attention. I worked considerable with the V3 API and that was rock solid. I'm having a difficult time with the new API. It has a lot of quirks.

My biggest issue now is that certain calls return an empty response with certain parameters.

For example, if I try to filter streams with a gameid and language this will return a result with 0 items sometimes while other times it will return the correct results. The behavior is very inconsistent.
https://api.twitch.tv/helix/streams?gameid=33214&language=en

It works 100% of the time without the language parameter.
https://api.twitch.tv/helix/streams?game_id=33214

It will also filter incorrectly if the parameters are not entered in alphabetical order which is not documented.

Allow game developers to rename a game without going through customer support agents.

Right now I am trying to go through the process of updating the game name, and it has been a **** for 6 months already. Took a month go get the update happen on GiantBomb, waited few months for Twitch to synchronize, which didn't happen, then started writing to support agents.

First reply to my ticket was 2 months after I opened it. Support replied with a canned response about renaming a user...

After reopening the ticket, several weeks later I get the ticket closed again, with another canned response, this time about adding a new game.

Reopened the ticket a third time, still waiting for next response for weeks, feeling hopeless.

Renaming a game seems a simple operation, it could be performed through the creator dashboard after you claim the game, just like you'd change the box art.

Such a feature would save me a ton of grey cells. Right now I'm not sure if the game will ever be streamed properly, if it won't get renamed before launch...

Like Bits transaction, it would be great to allow Channel points to be accessible from an extension.

The idea is to not expose channel points to the extension and work the same way Bits transactions are.

This would also need the addition of channelPointSku or allow sku product to have a bits value and/or a channel Point value.

• User click on a button


• Extension fires window.Twitch.ext.points.usePoints(pointsSku)


• User validate transaction


• (if user complete transaction )OnTransactionCompleted callback is fired with receipt containing channelPoint as the currency used


• (if user cancel or don't have the channel Points) onTransactionCanceled is called

To complete it, adding a filter on the endpoint GET helix/extensions/transactions would allow developers to only get Bits transaction, channel points transaction or both.

Channel points in extensions would help people to discover features, interact with extensions more and at the same time, give a way to regulate the interaction by using channel points instead of free actions.

When creating a clip via the Create Clip API, it is VERY limited compared to the (not for public use) GraphQL interface. Requesting that the following enhancements be made to the Create Clip API so that 3rd party apps can leverage them:
1) Add ability to specify the clip start time (number of seconds from when the broadcast started). Reason: when deciding when to create a clip, apps may want to look back 10-15 seconds instead of generating the clip starting from when the API is called.
2) Add ability to specify the clip title. Reason: currently, the API defaults the clip title to the stream title, with no option to change it.

3) Add ability to specify the clip duration (max 60 secs). Reason: current API defaults to 30 seconds with no option to change it.
4) (nice to have) Ability to access raw media MP4 files once created.
5) (nice to have) Ability to specify the clip playback speed (default to 1.0)
6) (nice to have) Ability to specify the clip preview image offset in seconds (default to 0 - start of the clip)