[C#] Using OAuth2.0 to get followed streams

[frankylift]

Hi!

I’m currently developing a new application in C# using WPF. I want to get the list of live followed channels of a user (https://dev.twitch.tv/docs/v5/reference/streams/#get-followed-streams).

I can make someone authorize my application to access that, but I don’t know how to use that authorization to get the followed streams.

Can someone explain me how that works?

Thanks

[george]

You can send the oauth token as a header or query string parameter. See the section titled “Sending Access Tokens” from https://dev.twitch.tv/docs/v5/guides/authentication/

[frankylift]

Thanks for the reply, but my problem is that I don’t know how to get the access token.

I don’t have a url to redirect the user after the auth. Is any other way to do that?

[george]

Some applications spin up a local web server and redirect back to localhost with the authorization code grant flow. You could also use the implicit grant flow - open a webview (or whatever the equivalent is in WPF) and grab the token from the URL hash after the redirect.

[Adrian_Schofield]

I’ve just been working on something similar, to be honest I’m no expert with WPF so I’ve put together a solution based on the following useful resources.

First you do need a very simple web server to listen for the response from the initial oAuth call, I used this as my starting point:

Your Ultimate Guide to App Development Services - Code Hosting

Second I set up a very simple Window containing one WebBrowser Control. The only bit of code is to set this to navigate to the initial Authorization url, something like this:

myWeb.Navigate(“https://api.twitch.tv/kraken/oauth2/authorize?response_type=code&client_id=fqyfzn1c10xqpzc54uok2vuv6l7bs1&redirect_uri=http%3A%2F%2F127.0.0.1%3A8080%2Fauth%2Ftwitch%2Fcallback&scope=user_read&state=OAUth2”);

Third take a read (I’m sure you already have) of this article particularly read about the Authorization Code Flow:

Authentication

Last bit, take a look at the code I posted here:

404 when using C# POST to finalise the oAuth Authorization Code Flow

You’re using put, not post. As an aside, you should be wrapping the response and stream readers in using blocks, or use try… Catch… Finally and dispose so that your aren’t leaking resources.

Make sure you fix the PUT to POST.

Then you’ve got all the pieces you need to get the oAuth token.

1. Spin up your web server listening to the url you configured as your redirect url in your Twitch application settings
2. Send the user to the Auth URL using your WebBrowser control
3. The user will have to enter their credentials, and maybe Two Factor auth details
4. On a successful attempt your web server should then get a callback
5. The callback for Authorization Code Flow contains a code
6. Using the piece of code I posted you can make the final POST to Twitch and get the oAuth token back in the Json response.

I am planning on writing a small sample for this as I went through quite a few iterations before I got it working, in the mean time I hope this helps.

[Adrian_Schofield]

I’ve written a sample, you can find it here, feedback most welcome.

adrianschofield/TwitchAuthWPF

[JJ_The_Bunny]

If you are hosting the web browser internally in your app with any of the various browsers that allow that, you actually don’t need a live web server running. You can catch the Navigating event and parse the url that is being redirected to as the token you need is one of the url parameters and not embedded into the body.

[Larklen]

You should modify your GitHub ASAP as it contains the Client Secret ID. Client ID is one thing to show but the secret ID should be kept from the public 100% of the time I believe.

[Adrian_Schofield]

Thanks @Larklen I’ve already invalidated the client secret. It’s so difficult to know what to do in these situations as you want to post working code but not post working application data if you see what I mean.

[Adrian_Schofield]

Could you elaborate a bit more? From what I can tell the Authorization flows always make a callback which means that you always need to be listening on the callback URL to be able to complete the Authentication and get access to the token? From my understanding (and happy to be corrected) that means you always need to have some kind of limited web server running.

[JJ_The_Bunny]

Hmm, I whipped up an example and either the auth flow has changed or my test has a web server at that address (but it doesn’t participate). Sorry for the confusion.