Best-practice auth for public OBS overlay + backend WebSocket outside

Hi Twitch team,

I’m moving an overlay from local testing to production. Broadcasters will add a public URL like:
https://<subdomain>/broadcaster/<random_hash>
The overlay runs in OBS (outside the Extension iframe). When a Bits EventSub callback fires, my backend pushes an animation event over a WebSocket to any connected overlays for that broadcaster.

Because the page is outside Twitch, there’s no Twitch JWT available in the overlay. My plan is:

  • Treat the URL as a capability link: <overlay_id> + a secret kept in the URL fragment.

  • The overlay page reads the secret from the URL fragment (not sent to the server in the initial GET), exchanges {overlayId, secret} for a short-lived server-issued JWT, then connects:
    wss://<subdomain>/ws?token=<jwt>

  • WS upgrade verifies aud/iss/exp and attaches overlayId/broadcasterId.

  • EventSub (Bits) → look up sockets by broadcaster_id → push animation payload.

Questions:

  1. Is this an acceptable approach under Twitch policies for overlays outside the Extension iframe?

  2. Is there any Twitch-provided token recommended for this OBS use case, or should I fully own auth as above?

  3. Any recommended validation pattern for the public overlay URL beyond strong random IDs + my own auth?

  4. Any guidance/limits for many WS connections from OBS browser sources (reconnect, rate limits, CDN/proxy considerations)?