[SOLVED] Keeping Auth for Login

API
1

I’ve browsed both:

https://github.com/justintv/Twitch-API/blob/master/authentication.md
and

I am trying to retain the user-session. I can successfully use the login button, it goes to my auth.php, and I can get the access token with no problem, however, if I check the status at any point, the status says authenticated:false. How can I retain the user session on my site after they log in?

2

Are you using the JavaScript SDK? It hasn’t been updated in over 4 years, so this is likely a bug that you’re running into. If you’re not using it, you would have to handle their login state with your own code along with your usual OAuth token storage.

3

Yes, I am in-fact using the Java SDK. If I shouldn’t be using that, could I get a really barebones walk through of how to do this? Login, check if logged in, and maintaining the session? I know it’s asking allot, but if I can get this down, I can probably figure out the rest with no issue.

Thanks for your help and advice!

Edit: Also, if the Java SDK is still viable, how would I go about using that to maintain the session?
Edit Edit: I also am successfully getting the auth token, so if I can just do something with that to maintain the session, that would be cool too.

4

Any ideas? I’ve messed around with it a bit more and I am not sure how to retain the session with this. I have the auth token, but I am not really interested in doing anything with the user’s account besides grabbing initial info. I just mainly want to retain the session while they are logged into Twitch after they auth.

5

Retaining a session isn’t specific to Twitch but a general part of web application development. You could do it client or server side but that’s a decision for you to make. If you look at the source code for the Twitch JavaScript library, you’ll see that session storage is done via two methods: sessionStorage and cookies for older browsers.

The authenticated field that you’re looking for is stored by just seeing if a token exists, so you could store a boolean saying they’re authenticated if you get an OAuth token back.

6

Yeah you’re right, I created a simple cookie vs last login ip for the auth token and am just checking to see if the auth still exist for the session. I am trying to keep it bare bones. Is there any real danger to storing the auth token in the cookie plain if I am checking every single page against the login ip?

7

Cookies are available to the domain they are set for. Typically with Cookies you want to make sure to set them as secure, and ideally HTTPS only access. Google ‘Secure HTTP cookies’, and do a little research on how to protect yourself and your users.

8

I am using forced ssl, along with attaching the token and username to a login IP. If for some reason someone, somehow, got ahold of the token and tried to perform an action client side with a new IP, it would reject the auth token and force them to generate a new one. I am also assuming that any action taken on a channel using an auth token would also need to come from the registered address client-side. Also, thanks for the tip with secure cookies.

9

Twitch doesn’t deauthorize tokens until the app is disconnected for the user. You cannot delete an auth token (from twitch) from the applications side. Generating a new token only creates a second available token to use to authenticate to the app.

If the (twitch) token were somehow compromised at any point, it would remain compromised until the user disconnects the app from their twitch settings page, under connections.

10

That’s insanity, why would they do that? Why wouldn’t the old token be destroyed when a new one is generated for that app? I am assuming to at-least prevent CSRF that the request can only come from the root domain of the registered domain on the app, or could someone just take that auth-token anywhere and start using it to act on behalf of that account?

As it stands right now, so long as they are coming from the same IP their auth (on my side) is fine and they can interact with the site as logged in, however, if their IP changes I force delete the cookie and make them log back in by re-authing. I thought this was the way to go, since it would eliminate someone stealing the auth token and interacting with my site as that user. What you’re telling me, is all that’s doing is generating yet another perma key every time this happens. If this is the case, how am I supposed to maintain a login session and provide logging in with Twitch without generating hundreds of these keys?

Thanks for any advice.

11

That’s been my ongoing complaint.

I would recommend encrypting the token with a key. If you issue requests from the server, never pass that key to the client, if it’s done from the client, try to create a unique encryption key such as the computers machine key, or a fingerprint key of ip + browser + misc items. A client key can never be perfectly secured, but you can make it harder to compromise successfully.

12

So basically, DON’T store the auth token plain text in a cookie, which made way more sense until you explained how nutty this is. My chief question is this, in what way can the account be compromised if I only have channel_read permissions and my site knocks them off if the IP doesn’t match their initial login one?

If I am using secure cookies and https, doesn’t that mean I need to physically steal their cookie somehow? If I had that kind of access to their machine, couldn’t I just directly use the site from the compromised machine? I will definitely be (at least) using a custom encryption scheme from here on out to store the auth key, but my real question is; could I take a stolen auth key and use it on a totally different website, or does Twitch check against the client ID, secret, and registered domain first?

I apologize for being obtuse, but that last thing just threw me for a bit of a loop.

13

channel_read scope, from documentation:
Read access to non-public channel information, including email address and stream key.

So if the token were compromised, the person who compromised the token would have the broadcasters email address, and the ability to stream (using OBS, XSplit or similar) on the broadcasters channel. Which means somebody malicious could stream something against TOS (IE: porn) and get the users account banned (either temp or permanently).

I’m not making claims that it will happen, just to be aware as a developer that what you do needs to be done with care, and try to make things as safe as possible for your users, who, when they give you OAuth tokens, are placing trust in you to keep those tokens secure.

The main way to steal cookie data is CSRF and XSS (Cross site request forgery, and cross site scripting) - Both are things you should read up on if you’re just learning.

A machine key is just a GUID assigned to a users computer, there’s nothing particularly special about it, but you can read up on it.

Also be sure to always use tried and true, vetted encryption algorithms. Your purpose is to supply salt keys to encryption routines, not roll your own encryption. (Salt is a technical term, google ‘Encryption Salt’ if you want to learn more)

14

So, if for example, you generated a token for your game app, and I took that token. I could use that very same token on my localhost. Twitch won’t see that the token is trying to be used somewhere else and block the request? I am somewhat familiar with hashing, crsf, and how they are performed.

Right now I am using symmetrical aes encryption, I encrypt the key once with a global secret key, and then I encrypt it again with a private unique key stored in their account. After that, I put it in their cookie. When I need it, I decrypt it twice in reverse order. The keys are pretty large, and as I mentioned I am using https and secure cookies. Am I missing something? It’s a bit harsh on the server, but would this provide an adequate level of protection for my users?

15

Here is an example of what I am talking about:

Here is the encryption class:

16

I don’t know enough about javascript php to confirm that implementation. Rijndael is a good encryption method though, but typically you want 256 or greater - but I seriously doubt 128 would be an issue.

[edit] sub/javascript/php

17

I will go ahead and bump it to 256, no harm. Just a little more cpu time. I would rather spend more money hosting than do something potentially insecure. Thanks for the advice, I appreciate the help.

18

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