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

Currently, if you launch an extension with a streamer whitelist, there is no way to remove this whitelist once the extension is live.

I would like to suggest being able to remove (And only remove not add) the streamer whitelist once the extension is live. This will enable doing 'beta-releases', which is a very common rollout practice and has a lot of benefits for the developer.

In this way a developer can release an extension to a set group of streamers who want to participate in the beta test.

Once the developer has determined that things look good and it makes sense to open the usage to all streamers then they can remove the whitelist and do so. If however the developer sees that things arent working as expected or user behavior isnt positive, they can rework the extension and release a subsequent new version and restart the beta.

This of course should not work in the opposite flow (Add a whitelist after an extension is live) as it could break for streamers who installed the extension but then werent in the whitelist once it was applied. So the ability should be one way. You can remove the whitelist after its live once but not re-apply it.

bits revshare is obviously not enough to build a sustainable small/medium business on twitch extensions atm (except 1-2 examples out of hundreds). reasons behind as I see them - extensions are for small streamers mostly. middle/big ones are not that into extensions as a product category. thus even being featured 24/7 doesn't provide enough viewers to actually get $1000-5000 dev payout for most of devs. not to mention retention aspect.

moreover streamers are not that eager for bits. their current meta is to grow subs.

so the idea is to provide devs with ability to work with subscriptions and get a share of it per tier whenever streamer is getting new sub with the extension. in terms of the amount - same 20% would do.