How to use HELIX API without Bearer Token

Hello,

I have a simple question. I could use Kraken API without needing a bearer token, just a Client-ID.

Now, the endpoint for “get top games” does not work without a Bearer Token.

Can I make it so that I don’t request and redirect my users to Authorize to get a Bearer token ? I really Just want top games to be displayed I don’t need any information from my users…

Is there a solution to this ?

Thanks!

If you want to make requests client-side then you have to use the Implicit auth flow https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#oauth-implicit-code-flow, and have your users log in to your site. They only need to connect to your app once, after that the auth process can be transparent to the user unless they disconnect from your app. Even if you don’t need any user data, you still need an OAuth token to make requests and if you want to do it client-side then the implicit auth flow required.

If you want to make requests from your Server, then you can just use the Client Credentials flow https://dev.twitch.tv/docs/authentication/getting-tokens-oauth#oauth-client-credentials-flow to get an App Access Token, which doesn’t require any user intervention to obtain, and make requests with that.

That solution SHOULD NOT BE USED.

It creates a publicly accessible endpoint that hands out App Access Tokens. That is a violation of the Twitch Developer Agreement, as well as a significant security risk.

App Access Tokens should ONLY be made available to servers within your own infrastructure, and should never be exposed to clients. If you need to make requests client-side, that is what the Implicit Auth Flow is for.

+1 Extreme Violation of the Developer Agreement

B. Keys. Once you have successfully registered Your Services, you will be issued one or more unique security keys, secrets, tokens, access codes, passwords, or other credentials (collectively, “Keys”). The Keys enable us to associate the Program Materials with Your Services and end users of Twitch Services. All activities that occur using your Keys are your responsibility. Keep them secret. Also, you may not sell, transfer, or sub-license them.

This service does the direct opposite of that.

Client Credentials tokens should not be used on the front end.

Only implicit auth or the users own token can be

The App Access Token is exposed.

Your function LITERALLY returns a the App Access Token to the frontend

{
“access_token”: “REMOVED”,
“refresh_token”: “”,
“expires_in”: 3600,
“scope”: [],
“token_type”: “bearer”
}

You mean this Access Token ?

You just violated the developer agreement, by posting your token publicly.

I have removed this

I’m sorry i copied the example from https://dev.twitch.tv/docs/authentication/getting-tokens-oauth where also the token is visible.

I don’t know it’s the example one if you don’t say it’s the example one

My bad, I’m sorry! All the tokens displayed are example ones.

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

Thanks you for the clarification!

So the easiest way would be to move the API calls to my Node server and do everything from it, which should not be hard to do. (essentially the server to server communication). I probably misunderstood on which kind of token is being used. I though the token returned would be an user token.

I’ve already fixed the point with Token limits by using redis for now where it is renewed after it expires.

Thanks again I will make sure to edit the post also.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.