Yeah ok, I’ve heared about that option. Twitch should probably give us a way to detect the default one too.
Yeah, I will be able to detect the button click event and read the content of the input textbox, as long as sending updated SE’s storage. Was that the thing you were worried about?
Sounds like you’d need to login with SE and/or leak a “secret” credential to this frontend system, otherwise anyone can screw with the SE data store!
To work with widget’s settings the broadcaster will need to login to SE via Twitch, so here is where the security is. Also I understood that OIDC implicit code flow returns a token that doesn’t last much time + the token will work only for reading rewards, isn’t it?
Correct, OIDC returns a JWT and a regular oAuth token
2) If the user authorizes your application, the user is sent to your redirect URI, with an ID token and optionally an access token (if that was requested):
https://<your registered redirect URI>#id_token=<an id token>&access_token=<an access token>
But the JWT (ID Token) only has a 15 minute clock on it iirc.
The access token should be the “regular” 60 day token.
See
For what flows return what kind of tokens.
I get what you’re saying, still the access token will work only for reading rewards, so no worries.
Another solution could be providing the broadcaster the link to the oAuth screen and using the form layout, the one used in the previous solution, to let the broadcaster input the whole redirect URL managing then the access token request with a simple function. No?
Probably this is the solidest “serverless” solution yet.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.