Getting App registered/ web setup from scratch. Total noob here

Alright. So as the title pretty clearly lays out. And I know there are 110 different already existing questions out there regarding the application registration, URI redirect. And pretty much everything in-between . But what I failed to see was an idiots guide to getting everything setup. Now first things first, I did attempt to lookup how to get everything going, I tried to look at tutorials, but apparently I need a tutorial dumbed down a little bit. Here is a list of the what I feel are important URLs I’ve already investigated before someone comments, “Try using search”.

> https://github.com/justintv/Twitch-API/blob/master/authentication.md
> https://discuss.dev.twitch.com/t/authentication-in-php-with-oauth/2149 <- I think maybe this one was intended to be the most idiot proof. But I'm still confused.
> https://github.com/Xxplosions/twitchtv-oauth/commit/815c29fa0ba307819abb658a0fae45a7aee43f52
> https://github.com/justintv/twitch-js-sdk
> https://blog.twitch.tv/client-id-required-for-kraken-api-calls-afbb8e95f843#.4wpwt6wpv <- The post that started this whole endeavor.
> https://www.twitch.tv/kraken/oauth2/clients/new <- Application registration page, we'll come back to this.

Starting off, I don’t know anything about anything really. The only reason I have a website is to host my APIs that I have created for use with NightBot. And I don’t even know much about that. Anyways, I know one of the first steps is going to be getting my application registered. Well, I have a little over 20 little separate APIs. Can I just register the one application, and call it good across all of the applications. Should I just combine them all into one big API so I only have to register one app? I want to make this as painless as possible for the people who are already using my APIs. So if somebody is using 3 of my APIs, they don’t have to register 3 APIs. I’d imagine that’s how it works. With the redirect URI, what is that?! Oh that’s the URL the user is redirected to after authentication. Okay, which authentication? The one where the have to goto a screen that’s suppose to be setup on my website where they can log into Twitch and authorize my apps? Or is it for after each time they call the API, and they get authorized to get the JSON data? So, should the redirect URI point back to my API, or should it point to like google or something since I don’t really have a website? And finally, what all extra files do I need to upload to my website since they have to authorize my app? Is there a way to run the API so that way whoever is using it doesn’t have to authorize my app? I know I have all the resources to get this going, I just get lost in all the technical terms. Any help is greatly appreciated, and thank you for reading this in its entirety.

I’ve never used Nightbot or created an extension for Nightbot, so I’m lacking some context for my answers. This answer isn’t an exhaustive look at OAuth. I would recommend reading up on it if you want more information. Grab your favorite drink and get ready for a lot of words. :slight_smile:

Let’s start with the Client-ID requirement. The only time you have to send the Client-ID is if you’re calling https://api.twitch.tv/kraken/. I looked through a few of your APIs and only see a handful that do this: Give, Kill, UpTime, Lick, Love, etc. Those will require that you add the Client-ID header. If you combine those into a single API, you can use one Client-ID. Otherwise, use multiple.

Next, let’s talk about OAuth authorization and authentication. Authentication is verifying the user is who they claim to be. In our case, they have a Twitch account and are logged in. Easy peasy. Authorization is different altogether. This is the user giving your application permission to take an action on their behalf. An example would be that your application wants to post on their channel feed. You can’t do that without the user’s explicit permission to the channel_feed_edit scope. The user is basically giving you a way to impersonate them to take certain actions. Those actions are governed by scopes in OAuth. You will also see these in the Twitch API documentation. When you send a user through an OAuth flow (either implicit grant or authorization code in Twitch’s case), your application will declare which scopes are important to it and request access to those depending on what it needs to do. The user has full rights to say yes or no to that request.

Now, when the user authorizes your application, a code or token is generated depending on what you request. You’ll get a code for the authorization code flow and an access token on the implicit grant flow. With the authorization code, you will have to make another Twitch API call to get the OAuth token. With token, you just get the token directly. You might ask why you would the flow with the extra call. There is a larger explanation that I won’t get into, but the short version is that each flow is suited for different environments and each flow has different security concerns. Again, if you read up on OAuth, you’ll read about these flows.

How do you get the tokens or codes? Well, that’s where the redirect_uri comes into play. When a user authorizes your application, the OAuth flow redirects the user back to your redirect_uri. This should point to a web page that you own since it will contain information to get an OAuth token for that user. In the authorization code flow, your redirect URI will be:

https://[your registered redirect URI]/?code=[CODE] 

You must then parse that URL parameter in order to exchange it for an OAuth token. In the implicit grant flow, your redirect URI will be:

https://[your registered redirect URI]/#access_token=[an access token]&scope=[authorized scopes] 

You must parse out the access_token URL fragment, which is your OAuth token. Once you have a token, your application must send that value as the Authorization HTTP header when making an API call.

Having said all that (hope you’re still with me), you may not need an OAuth token. This all depends on which Twitch APIs your application is using. If the Twitch API has a required scope, you need a token. An example would be the /feed/:channel/posts endpoint. If the Twitch API doesn’t have a required scope, you don’t need a token. An example would be the /channels/:channel endpoint. In all cases, you need a Client-ID.

Finally, I’ll answer a few questions directly:

…what all extra files do I need to upload to my website since they have to authorize my app?

The only extra file you would need is the file at redirect_uri to grab the authorization code or OAuth token. Again, this is only if you actually need OAuth.

Is there a way to run the API so that way whoever is using it doesn’t have to authorize my app?

No. The only way they don’t have to authorize is if the APIs you’re using have no required scopes.

I hope this helps!

3 Likes

Thank you for your time and effort put into that post. That does help a little. So, none of my APIs have a required scope. At the very most, I think I’m pulling data from 6 APIs and that’s for the most part just basic profile information. So, I don’t have to mess around with OAuth. So, than I just need to have my Client-ID. But in order to get a client ID, I need to input something for the redirect URI, and I only need that if I’m using OAuth. So should I just put http://localhost in for the redirect URI? Just so I can get a Client-ID at the very least? My APIs are very basic, display very basic information about channels, or just even checking to make sure a channel exists. And on the Application registration page, can all of my APIs get registered under the same name? Say “Owyn APIs” or do I have to put like “UpTime API” so on and so forth

You can set the redirect URI to localhost or just to your base website address if you’d like. Twitch won’t redirect to that URI except in the case of the OAuth flows. Just an note: you will need to set the URI if you ever need OAuth.

For the Client-ID, you could certainly do it under one Client-ID for “Owyn APIs” if that’s how you’d like to approach it. The Client-ID is simply used to identify your application.

Thank you for all of your help and assistance DallasNChains. I have modified my UpTime API to now have the Client-ID in the header of each kraken request. And I’ll be going through the rest of my APIs shortly to get them up to par. But since I’m still super confused about the OAuth, not in the sense of how it works. Just what I need to get it going on my end. I’ll skip on getting that setup, since all of my APIs should only require a Client-ID. Which as I understand is safe to share, so I won’t remove the Client-IDs from the pastebin. It’s just the secret that you have to keep confidential, and since I’m not using OAuth, I don’t need to worry about that either. Thanks again!

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