Hello Hello,
Definitely, I disturb you every day.
I have a question regarding the necessary authentication on the Helix API from April 30th.
To generate my access_token, I use tools found on the internet when it came to using Pub / Sub and TMI as part of the tools I am developing. It does not contact the API directly yet, but if I follow what you said about this update, on the one hand the Oauth becomes mandatory for any request to the new API, but I also read that this Oauth should have been generated with the same client_id used in the request.
The problem is that I do not (and fortunately) know the client_id of the applications I have used on the internet.
My main application using the App Access Token method, it does not have this problem, and then it is registered as an application in my developer area so it does not pose any problem, I have all the info.
Will this mean that if I want to be able to query the new API with my Pub / Sub and TMI bots, I absolutely must have generated their access_token thanks to applications which I control and therefore I know the client_id c ’ is that right?
Thank you in advance for your reply
in short yes.
And you should be using your own ClientID’s/secrets so that you have full control.
At any given point the tools you have used to generate Access Tokens, can disappear or get banned, then all your tokens break because you used someone elses tool
Additionally if you used someone elses tools to generate an access token, you cannot refresh that access token as you don’t have the client secret in order to do so, and thus you have to manually go and do the oAuth flow instead of the automated creating of a new token from the refresh token and client secret
In this case, do I have to create an entire application after registering my program?
The owner of the channel is not necessarily adept at the technique. Can I do all of my Oauth feeds with Postman for example?
“Registering my program?” I’m not sure what you mean by registering your program
No.
For me I have a website, I send the streamer to that website and tell them to click the login button, that sends them thru an oAuth loop, and I store the access token/refresh tokens in a database.
I load everything I need for the streamers I work with from said database and renew the keys automatically
Is an example of such a server, it just doesn’t store the tokens into a database (code doesn’t give an opinion on that). And gives no opinion on automated renewal, since it doesn’t do storage
This requires hosting a mini application since otherwise the Oauth process cannot return to local, right?
And then the person whose authorization I want does not necessarily have my localhost. It is rather annoying and constraining to put all this in place just to obtain only once a first access token and refresh token that we will refresh anyway programmatically in my program right?
Are you sure the postman Oauth can’t handle the whole process?
Doesn’t have to be a mini application, (like how node runs) can just be PHP scripts or other “normal” web programming/scripts.
An oAuth process can return to local. But if you are working with streamer fred, who is in the US and you live in the UK, (like I do for example), then the oAuth loop returns local to them and that’s no good… (Without building a program that the streamer installs, but then that means you are potentially leaking your client secret)
So it’s easier to run this on a remote server, since then you also can use Twitch Webhooks and your application is always online.
No since step one involves “redirecting the user to Twitch to accept or decline access to your application”
Traditional oAuth isn’t design to operate how you are trying to run it.
TLDR: Run this all on a remote server and you can utilize everything Twitch offers API wise and simplifies getting access keys from streamers you want to work with
You can do whole process with postman, you just need to configure like that
In your app on twitch, you need to write this callback url :
https://getpostman.com/oauth2/callback
On postman the same callback url
https://getpostman.com/oauth2/callback
On postman on Auth URL
https://id.twitch.tv/oauth2/authorize
On postman on Access Token URL
https://id.twitch.tv/oauth2/token
Don’t forget to switch to “Send client credential in body” on the last selector.
When you click to “Request token”, a web browser from postman is opened and do the whole twitch graphic process.
I got all my tokens for this
I will just send the postman collection to my streameur for run the process.
Thankx 
Postman is great for testing/development.
But it’s not advised to be used for production/end streamers to poke about with.
With this you have to
where as if you set up a proper production tool, you send them a link.
No faff/no setup it just works.
Postman involves too much faffing about and the fact you are juggling client/secrets, and cannot automate the collection of the streamers access token.
It’s not a good idea, and it may be a violation of the Developer Agreement if you are storing the Client Secret in something you don’t control (or passing the client secret to a streamer to enter manually into postman)
Postman is a tool for development and testing. It’s not a production ready tool/app
I am not a developer that I would call public. I only develop for a single streamer. The client_id and client_secret will not be in the wild since I have a close relationship with the person concerned. Once done, it will delete the software and the collection. I would not even give him the collection for real, I would take control of his post. I fully understand the fact of not letting its two data drag.
Unless I have new scopes in the future, only I would have the client_id and client_secret data so I don’t break any rules. Finally I hope ^^
Thanks for your help, it’s already better than going through third-party applications on the internet. I keep a maximum of control, I would say that it is a compromise for the moment.
Then what do you do if you token dies for some reason (and/or new scopes and API endpoints appear) and you have to fetch a new token from the streamer? You spend two seconds adding the new scope to your existing web app, or spend ages plumbing it into Postman and manually fetching stuff between you and the streamer?
It’s not a good compromise since this comprise potentially violates the developer agreement you agreed to when you made a ClientID/Application.
But in the end it’s up to you. Just generally speaking the web app approach is easier and safer in the long run
1 Like
