In Clarification:
Front end shouldn’t use/expose a token that is not the users own token.
Your blog post/service does exactly that.
It generates a Client Credentials (AKA server to server) token, and returns that for the front end to use.
Which then means you are using your “Server to Server” token for “Frontend to Server” requests, which is not the use case for this type of token.
Front ends should only use tokens generated via implicit auth, but may use the users own token generated via regular auth, if alternative authentication is in place first. Like login to the site using username + password, which will fetch and use the token for the linked users Twitch Account, but generally there the front end would call the backend and the backend would piggy back the request protecting the users token from theft via MITMA for example.
Generally, only use a token directly on the front end if it’s the users own token.
An App Access Token doesn’t belong to the user.
You really should not be doing
So the token will be request, when someone new is accessing the website where I save the token on the frontend into a cookie.
This is a violation of the developer agreement.
And you are essentially giving someone your password to your Twitch account, and can result in users taking and misusing this token and getting your whole client ID terminated and/or banned from the Twitch Dev environment.
Your service should generate, store and use a token server side. Never sending the token to the front end.
And your front end calls your backend, the backend makes the request (and checks any caching layers first).
I have written a pair of examples one in Node and one in PHP for creating and storing server side tokens
The nodeJS example will store in Redis for recall and use by the server it’s never sent/visible to a front end user.
The PHP one is unnominated on where to store, and just dumps the token in a JSON file for recall and use
EDIT I almost forgot
Using this method, you’ll also hit the “token” limit, if you have 26 people using your website, the first token will be invalidated. Due to the 25 token limit.
If you generate 26 active app access tokens, the 1st app access token is invalidated.
So then your website will generate a new token for the 1st user, killing token 2, and so on.
This limit exists, to prevent you doing exactly what you are trying to do, use an app access token on the front end.
Regarding user tokens: you can generate as many user access tokens as you want as long as each user is different. You can’t generate 26 tokens for the same user