Official authentication support for Twitch via the ``--twitch-oauth-token`` and ``--twitch-oauth-authenticate`` CLI arguments

had to be disabled in Streamlink's :ref:`1.3.0 release in November 2019 <changelog:streamlink 1.3.0 (2019-11-22)>` and both

arguments were finally removed in the :ref:`2.0.0 release in December 2020 <changelog:streamlink 2.0.0 (2020-12-22)>` due to

`restrictive changes`_ on Twitch's private REST API which prevented proper authentication flows from third party applications

like Streamlink.

The issue was that authentication data generated from third party applications could not be sent while acquiring streaming

access tokens which are required for watching streams. Only authentication data generated by Twitch's website was accepted by

the Twitch API. Later on in January 2021, Twitch moved the respective API endpoints to their GraphQL API which was already

in use by their website for several years and shut down the old, private REST API.

This means that authentication data, aka. the "OAuth token", needs to be read from the web browser after logging in on Twitch's

website and it then needs to be set as a certain request header on these API endpoints. This unfortunately can't be automated

easily by applications like Streamlink, so a new authentication feature was never implemented.

.. _restrictive changes: https://github.com/streamlink/streamlink/issues/2680#issuecomment-557605851

In 2019, Twitch has started sporadically embedding ads directly into streams in addition to their regular advertisement program

on their website which can only overlay ads. The embedded ads situation has been an ongoing thing since then and has been turned

off and on several times throughout the months and years, also with variations between regions, and it has recently been pushed

more and more aggressively with long pre-roll ads.

While this may be an annoyance for end-users who are used to using ad-blocker extensions in their web-browsers for blocking

regular overlaying ads, applications like Streamlink face another problem, namely stream discontinuities when there's a

transition between an ad and the regular stream content or another follow-up ad.

Unfortunately, entirely preventing embedded ads is not possible unless a loophole on Twitch gets discovered which can be

exploited. This has been the case a couple of times now and ad-workarounds have been implemented in Streamlink (see #3210) and

various ad-blockers, but the solutions did only last for a couple of weeks or even days until Twitch patched these exploits.

**To filter out ads and to prevent stream discontinuities in Streamlink's output**, the :option:`--twitch-disable-ads` argument

was introduced in :ref:`Streamlink 1.1.0 in 2019 <changelog:streamlink 1.1.0 (2019-03-31)>`, which filters out advertisement

segments from Twitch's HLS streams and pauses the stream output until regular content becomes available again. The filtering

logic has seen several iterations since then, with the latest big overhaul in

:ref:`Streamlink 1.7.0 in 2020 <changelog:streamlink 1.7.0 (2020-10-18)>`.

**In addition to that**, special API request headers can be set via :option:`--twitch-api-header` or special API request

parameters can be set via :option:`--twitch-access-token-param` that can prevent ads from being embedded into the stream,

either :ref:`authentication data <cli/plugins/twitch:Authentication>` or other data discovered by the community.

tokens are calculated using sophisticated JavaScript code which is infeasible to re-implement, as it not only involves

obfuscated code that's much harder to reverse engineer and to extract data from, but also a custom JavaScript virtual machine

implementation where bytecode gets interpreted which is encoded prior to that using randomization patterns. The interpreted

bytecode performs various checks of the user's web browser and its features, and then determines whether the client is legit

or not. The goal is to prevent bots and third party applications from accessing streams.

Client-integrity tokens were treated as an optional request parameter when getting streaming access tokens.

This changed on 2023-05-31 when Twitch made them a requirement, and it broke Streamlink's Twitch plugin (#5370).

Since the only sensible solution for Streamlink to calculate client-integrity tokens was using a web browser, a new

implementation was needed which could automate that. So in ``6.0.0`` the

:ref:`streamlink.webbrowser <api/webbrowser:Webbrowser>` API was implemented, which requires a Chromium-based web browser being

installed on the user's system. See the :option:`--webbrowser` and related CLI arguments for more details.

However, a couple of days after Twitch made these changes, they reverted the requirement again, but in order for Streamlink

to be prepared for such requirements to be turned on again, the webbrowser API was added nevertheless. The decision was made

to only use the webbrowser API when getting an access token fails, so launching a web browser unnecessarily could be avoided,

even though it would run invisibly in "headless mode". Should client-integrity tokens be made a requirement again, then

Streamlink will cache the generated token in the plugin cache after launching the web browser once. This cache can be cleared

using the :option:`--twitch-purge-client-integrity` option.