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 IRC gateway passes whispers using the WHISPER code:


[16:36:15] [@] @badges=bits-charity/1;color=#3E2E18;display-name=foo;emotes=;message-id=2;thread-id=21001676_470220570;turbo=0;user-id=2109996;user-type= :foo!foo!foo.twitch.tv WHISPER myuser :this is a whisper

But I am unable to find any reference to that code on https://dev.twitch.tv/docs/irc/commands where I would expect it, or any other documentation page under the "Chatbots and IRC" section.

I would suggest adding the WHISPER command to the list of commands at the top of the page on the IRC: Commands section, something similar to:

WHISPER Receive a Whisper message from another user


and then the prototype at the bottom, to include the fact that it appears the WHISPER command is (appears to be) a one-way command (the server can send a WHISPER to you, but you can't send a WHISPER to other users. (When I tried to send a whisper, I got: [16:45:58] tmi.twitch.tv reported an error: WHISPER :Unknown command).

Or maybe this is deprecated or not final yet, but I figured I'd point it out just in case it was an oversight. Thanks for all the hard work!

Right now, most of the PubSub topics are inconsistent with each other (understandably so). This, however, is focusing on cleaning up some of the ChannelPoints event data that is either unnecessary, redundant, or unclear:

As a note, the information stripped away from the structure is not invalid data, but rather data we likely don't need per message and instead should have a fetch api like manner. One example is the image objects that are likely to never change in the lifetime of a reward. This would save needless encoding as well as any data costs there may be on either side. When discussing ~512 bytes, some people will assume that is not a lot, but when scaling that up to something that people have no monetary requirement to activate, then we are talking about data sizes several magnitudes larger across the site.

Example of new structure concept:

Cleaned up structure:

{

    "Time": string,

    "Id": GUID,

    "Channel": User (see below),

    "Reclaimer": User,

    "UserInput": string,

    "Status": string, -- ONLY If we can receive things other than "FULFILLED"    

    "Reward":{

        "Id": GUID 

        "Name": string

        "Prompt": string

        "Cost": int,

        "MaxLimit": int, -- 0 if no limit is present.

        "CurrentCount": int

    }

}    


User Structure:

{

    "User": {

        "DisplayName": string

        "UserName": string

        "Id": GUID (currently an int encoded as a string)

    },

}

It would be great if we could have a list of the status codes and their reasons so we can write code to prepare for handling those errors, instead of logging them and dealing with them as they happen - for all endpoints. These exist, for the most part, in a lot of the newer endpoint documentation, but a lot of the older endpoints were rushed in their documentation and we have little information on what responses to expect. Sometimes we get 200s, 202s, 400s, 410s - and having to just "wait" or try to plan for them is a big frustrating. We have these Response Codes for less than 10% of the endpoints that exist in Helix (4/50)