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

Pagination on some Helix endpoints, such as Get Streams, is just bad, and can lead to endless looping. So here are some suggestions.

The goal of any solution would be for any dev paging through any Helix endpoint to have a clear and reliable indication of "there are no more results, you can stop pagination". And if for whatever reason that can't be indicated, the endpoint should safely return an empty data array rather than looping the user back to the start.

Currently, the final page of the Streams endpoint still contains a cursor (for use in before) so simply relying on the lack of a cursor can't work.

One solution may be for Twitch to validate the cursor on their end, so for example if that final cursor is used as the after value, rather than returning to page 1 (like what would happen with any request lacking or having a bad after value) there could be a check and if that cursor isn't appropriate for paging forwards then there could be a response with just an empty data array, and a cursor that allows paging backwards still with before but the same after object in the cursor so any repeated use will just return to the same final/empty page rather than the start.

Another suggestions that has come up would be for the inclusion of an additional pagination value in addition to the already existing cursor that the endpoint returns that can be a simple flag to indicate if there are more results (this could also be used to indicate if you're on Page 1, so unable to use the before param).

A final suggestion would be is if it's possible to encode metadata related to the pagination state in the cursor, so Base64 decoding it could give a dev details such as if they're on the final page, their current page, etc... I don't think this would be the most user friendly option though, as ideally devs shouldn't need to touch with the Decoding of a cursor.

All of these ideas should be non-breaking, as they don't change has cursors function, from the dev side of things and I think the first option, of the final cursor returning a page with an empty data array could be best as this could stop any endless loops in existing implementations, where as additional flags wouldn't help until the dev integrates that into their apps.