Currently in the stage where I have to integrate oauth with my extension, for the broadcaster on the configuration page as a first-time setup.
I have this approach that works, and I can’t find any policy in the docs about it.
Have javascript open a popup window with the auth url
Let the user authorize and redirect back to my EBS API that prints the access and refresh token in a JSON response, with the keys encrypted of course
Close the window and get response with the encrypted keys
POST the keys to another endpoint on my EBS and proceed with first time setup (store the keys and such)
Is this approach good or nah? Any security flaws? The only thing I could potentially see as a security flaw is sending the access token back to my EBS, on step 4. I could let the redirect page do everything, instead of printing the keys and sending them to another endpoint, but this would eliminate any kind of oauth access “outside” of the extension. If I use the redirect page as the “first time setup”, it could be done for ANYONE authenticating through my app if they got the auth url.
Please let me know if I should try to elaborate more.
If there’s a better and an actual correct way of integrating oauth in to an extension, please let me know.
I’ve searched around and found old threads that were saying there was a config-input in the extension dashboard where you could pass oauth scopes and the extension would automatically integrate it for you, but that has been removed now (?).
I don’t understand what you are trying to do with steps 3 and 4. Why do you want to send the tokens back to the user, only for the user to POST them back to your EBS which already has them?
Because the user is redirected to a page on my EBS on authentication, which is used for signing in and such, not first time setups.
I should not perform any first time setup just because a user signed in through Twitch, instead I fetch the tokens and call another endpoint with them as parameters.
I could probably get the ”code” parameter instead and pass that as a parameter to the first time setup endpoint, which then would get the tokens.
I think you are misunderstanding how the OAuth handshake works. The user is redirected to your EBS after they sign in to Twitch, and this redirect provides you with the code parameter so you can process the login.
My OAuth flow looks like this:
User visits config page, clicks oauth link
Twitch OAuth pops up in a new window, asking the streamer to login with Twitch
When they click ok, the popup window makes a GET to my EBS with the OAuth code
My EBS validates the code, stores the access tokens, then renders a blank page with some Javascript that calls back to the config page with success or fail.
The config page closes the popup window, then shows an error for failures, or show the next configuration stage on success.
In your first example, your EBS already has the tokens at stage 2, so it doesn’t make any sense to send them back to the config, and then back again to the EBS. Just send success/fail back to your config page, and have the state transition based on that.
Yes, I do understand that the user signs in through Twitch. If you do the first time setup for the broadcaster on the redirect page, anyone with the link is able to perform a first time setup for their account even if they don’t have the extension installed.
What I am doing by sending the tokens back to the config page, then POSTing them to the EBS again is to make sure the authentication was called from the config page.
For exempel, my redirect uri is a php script that gets the access token for the code specified from the authentication, the script then gets the user information for this access token, stores the user in a ”broadcasters” table together with the tokens. Now, if this user is not even using the extension, he will be in the broadcaster table without even using the extension on his channel page. I mean, there’s no harm having the user there, but it’s unneccesary to store more tokens than needed.
Okay. If you’re really worried about people hand-crafting Twitch OAuth queries (which requires them knowing your OAuth callback url in advance) and doing legitimate Twitch signins just to get their details in your database without installing the extension… Then just use the optional ‘state’ parameter in your OAuth calls, which is in the authentication docs guide, and is there to solve this exact issue. Get a token from your EBS before you create the OAuth link, or just send the JWT.