Our app logs in with the twitch login info, does the needlessly complicated “dance”, and logs in fine. The problem is that the oauth stops working about a day after. How do we choose how long the oaths last, and why is it so short by default?
From my understanding, it allows increased security. Your application will have to handle refreshing tokens. I’m in a similar situation in figuring it out as well.
If your app has a server-side component, try using the “OAuth Authorization Code Flow” documented here (https://dev.twitch.tv/docs/authentication/getting-tokens-oauth/). I get non-expiring tokens using this, but I don’t believe that this situation will last forever and that Twitch will start issuing expiring tokens for this authentication flow, though I suspect the expiry time will be longer than tokens that are issued using the implicit code flow.
Also, the “dance” is not needlessly complicated. Sure, it is complicated, but not needlessly so. It is a standard documented here (https://oauth.net/2/) and it is designed to give you access to a user’s account securely. The OAuth standard docs links to a RFC that outlines the threat model and it is worth a read (https://tools.ietf.org/html/rfc6819).
To allow for applications to remain authenticated for long periods in a world of expiring tokens, we allow for sessions to be refreshed, in accordance with the guidelines in “Refreshing an Access Token” in the OAuth2 RFC. Generally, refresh tokens are used to extend the lifetime of a given authorization.
Token expirations do not affect existing tokens. In the future, we will revoke permanently-lived sessions.
Forever tokens are going away for user based tokens
The issue lies with clientside non-web applications. The authentication process is quite disrupting for the user because they need to switch to a browser for it. Necessary and acceptable as long as it doesn’t have to be done too often.
However using a refresh token is no option for a clientside app, because it requires a client secret in the requests and there is no way to store a client secret securely in a clientside app. The guide itself says “Client secrets are equivalent to a password for your application and must be kept confidential. Never expose it to users, even in an obscured form.”, so e.g. storing it in compiled code would not be acceptable, since that is merely obsured (there would always be ways to retrieve it, since the clientside application itself needs to be able to read it).
Maybe I’m missing something, but I’m really not sure how Twitch expects clientside non-web apps to handle this.
Edit: One way would probably be to use Authorization Code Flow through my own server, but I fail to see how having to handle user access tokens on my own server (even if I would never have to permanently store them) would add any security. Especially since I need the access tokens purely clientside, so there’s really no reason for it to be process anywhere except at Twitch and locally on the user’s computer. I’d rather be able to just specify that a user access token should be kept valid for e.g. a month or even just 2 weeks.
You need to refresh the tokens automatically. However after a few days I kick out the users automatically so they re-validate. I believe this is required by twitch so you aren’t constantly authed into someones account.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.