Only if the Braodcaster gives you their account password and 2fa code.
Which is clearlly impractical and not good for security.
Hence oAuth exists to provide this instead.
Rent a server from any reputable server provider, or VPS provider or cloud provider and deploy your code.
The same server will also store your access and refresh tokens for the streamer.
Without owning “hosting” of some sort you are stuck. Since you need to secure those streamer keys.
Since you intend to deploy to SE Widgets, where are you going to store/host the streamers access tokens and refresh tokens? And any API/EventSub/PubSub interface you need?
In theory, yes, but then where do you host/store your access keys and any scripts to refresh those access keys and your API/PubSub/EventSub interface?
Without a hosting solutions you run into problems.
No hosting provider? Well then you go implict auth to get a key, but that key is not refreshable and the broadcaster needs to manually provide a new key periodically.
Hence, you should use regular oAuth to get a token and refresh token and host an API/PubSub/Eventsub interface layers.
Without the server, you have to use the “wrong kind” of oAuth and then the streamer has to manually give a new key periodically, instead of automagically.
Correct, all tokens expire.
For security reasons. If you leak a token, you don’t want someone to be able to abuse that token forever. Sure then the streamer will disconnect the app and start all over again.
But as long as you didn’t revoke the refresh token (and client secret) then you are fine. As you use those to generate a new access token, if the leaked token gets revoked (via the revoke API for example)
Forever tokens are bad for security.
I run these services for streamers.
So streamers use my instead of SE. I’m able to provide whatever for those streamers in a way that is not constriained by the limitations of SE Widgets or what SE provides
Sure this could work.
But you still have the problem of where do you host your oAuth interface? And the thing that stores the Access and refresh tokens? To make the access token available for the pure front end SE Widget to use the access token?
In this example I’d make the SE Widget call my own system so it doesn’t leak the access token. Granted it’s perfectly fine to show the streamers own access token to themself, but again you want to protect the access token from others viewing it. So my Overlays/widgets call my server with a unique Key and that matches to data internally, so if my Overlay URL gets leaked, no one acquires the access token.
Which is possibly what could happen with this SE Widget as you describe.
With an SE Widget, it will need to be able to call, the hosting you don’t want, to get the access token and/or the updated access token when it’s refreshed.
Which takes us back to the no hosting solution or using implict auth, which means when the token dies, the streamer will need to interact with the overlay to provide/obtain the new token, as you don’t want to provider hosting.
So you are stuck in a loop due to how you wish to implement.
The only safe way is with implicit auth, which means the streamer will need to give a new token periodically, thats if they even notice that their widget stops working due to a dead token!