Let’s assume I want to write a local, native desktop application to upload videos, so I would of course have to use OAuth2 for authentication. It is one thing to open a browser window or embedded browser component to have the user log in and grant permission, but with the redirect URL, there’s no online server running and also no server on localhost. I would very much hate to being required to set up an server endpoint for this purpose, managing user accounts there while I can’t know the users of the software beforehand, posing a security risk and also another single point of failure. I could set up a server on localhost, but that would be the default and not only for testing purposes, and I’m not sure about the security implications if local server and the native application obtain the response from the redirect. I wonder, on the other hand, how one can stream with OBS by manually copying the streaming API key into the local application, why shouldn’t this work for the upload API, too? Couldn’t you add a bool flag in the request URL that asks for the access_token to be displayed as nice HTML as result of form submission while the redirect parameter would be removed? If not, would it be an option on localhost to just display the access token to the user? Both with the intention of having him copy it into the native application, or would that break OAuth2 procedure significantly, so the local server would also need to actually be the “native” application, so the access_token can be obtained, handled and stored within the application code without showing it to the user and eventually copying it to the unsecure clipboard?
I know that there are a few similar threads, but after 10 days of no reply, they were automatically blocked, and sometimes they already have a local server running.
Another thing: shouldn’t the redirect URL always be HTTPS if it’s not localhost, even if you don’t check the certificate or if the certificate changes or should be compromized, in order to prevent people on the network sniffing the tokens in the clear and limiting the damage to whoever controls the redirect server?
It would be “best” to make a website that would do the auth loop and present the oauth key to the user to copy/paste into your Application.
Otherwise if your App was doing the oauth loop itself, you would have to distribute YOUR application secret with the app, which is a bit against the rules. Sure you can make your App require users go setup their own clientID and secret but thats a mess for people to do.
Either make a website that lets people go thru the loop then copy/paste out the oauth key.
Or you could make your app login to your website as a separate auth and fetch prior stored oauth keys. So your website would have it’s own accounts system with a linked TwitchID and associated oAuth that your native app could fetch and use on demand.
I think chatty used to spin up a local server and oAuth loop would loop back to that but I think they dropped that when people get iffy about distributing secrets.
What you can do is have a very simple web server in the application listening to localhost and providing a single page. Use implicit auth flow with that page and have a script on the page POST the token to the very same URL and have your application grab it at that point. Copying from the page instead of having the page POST it would work just as well.
This means you don’t need to have a server and don’t need to distribute your application secret to your clients (which you should definitely not do). It’s also functionally (and security-wise almost) the same as implementing a browser within the application to use implicit flow directly.
Regarding best (practice) in such a case: if you’re talking about an online website, wouldn’t it me as the operator provide a chance of obtaining access_tokens from users I have no relation to? If this approach avoids one OAuth related security risk, wouldn’t it introduce another? Except if it’s a trusted party, like a Twitch endpoint to display the access_token or if I could become trusted enough (for example, restream.io does it this way with the streaming API key, but they also probably take in stream data to distribute it where I never want to see a single one of the videos uploaded via my application, means: they have a good reason to be trusted, they actually work with the data).
I don’t think that I have to distribute my or any given secret with the package, as I have it kind of working (I assume) with just sending the user off to a browser by only providing the non-secret client_id, and the target URL for sending the login/grant form does the redirect in the browser while containing the access_token, which at the moment results in “Unable to connect” to localhost as no server is running. If I could reference a local file via relative name or absolute or file://, but the latter could expose user paths to Twitch.
I think I could start node.js locally and then write the access_token to the file system (or pass it to my application in some way) or display it for copy/paste, but then the question could become, if I already have to use node.js, the entire application could be made with JS+node.js, and then there’s no reason any more to have it as a local application, could also run on the web, and as it runs in the browser, it could be difficult to explain to users that it’s all local and I as developer get to see nothing of their data or secret keys. OAuth is the same thing the other way around: native applications specifically need to open the browser to have the user logging in with the visible, verifyable domain of Twitch in the address bar for them to believe that they don’t provide their password directly to my code.
Thank you very much for your reply, it gets me thinking about an online model.
That’s another helpful suggestion: I could avoid node.js and see how to make a very primitive but sufficient web server for this purpose listening on localhost. At the moment, I believe that something along those lines as described by you could very well be the best solution. I’m not an OAuth expert nor did I use it before, but I read the O’Reilly book on it some time ago, and in there is the strong recommendation that one should not bring his own native login forms and even embedded browser components are a little bit suspicious, as the idea is to teach the user that he should only use his normal browser as it is supposed to be independent from my application code, but browsers running as separate instances could potentially expose their data to other applications by now, so this concept is fading a little bit and of course doesn’t help in a scenario of a fully compromized machine. Anyway, I want to do my best and are thankful for advice from people who deal with such issues regularly. And yes, I attempted OAuth Implicit Code Flow (User Access Tokens), which has its own issues security-wise according to what I’ve read, but it’s more or less the same like the streaming API key. At least, it’s still sandardized OAuth2, keys are at least revokable on the server-side and there are separate keys per application.