164 results found

1. Webhooks (Un)Subscribe Parameters

   From: https://github.com/twitchdev/issues/issues/14

   Brief description

   https://dev.twitch.tv/docs/api/webhooks-reference

   the hub.topic section is out of date, in the JSON Body Parameters

   Expected documentation

   Just changed it to something like "refer to later in this docs for the available topics"

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Planned  ·  0 comments  ·  Documentation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Get Broadcaster Subscriptions Events

   From: https://github.com/twitchdev/issues/issues/8

   Brief description
   The subscription events API is documented as a Webhook topic. but not as a API Endpoint

   https://dev.twitch.tv/docs/api/webhooks-reference#topic-subscription-events

   It used to be in the documentation but is missing

   Expected documentation
   https://dev.twitch.tv/docs/api/reference#get-broadcaster-subscriptions

   But for
   https://dev.twitch.tv/docs/api/reference#get-broadcaster-subscriptions-events

   8 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Documentation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Please document optional OAuth 2.0 authorization flow parameter "nonce"

   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

   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… more

   18 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Investigating  ·  1 comment  ·  Documentation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. How to link out on a mobile extension

   Twitch documentation does not state how to handle opening a new window on a mobile extension.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   Planned  ·  0 comments  ·  Documentation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close