Similar to the approach above, I settled on this:

Firstly I make rest GET with my normal JWT token authorization and get a new unique uuid "sseToken" back from the server.

On the server side, when the GET comes in and is authenticated, I map the authenticated internal user ID and an expiry datetime five seconds ahead against that sseToken as the key in the "pending connections" map.

In the JS client, upon receipt of the sseToken from the GET request, I then issue the new EventSource() with the sseToken in the path (but could be a param - whatever works for your server setup).

When that SSE endpoint is processed, it confirms the sseToken is in the pending map (ie was issue by the GET request and has not yet expired) then removes it from the pending map. In a separate map (also keyed by the sseToken) I create the actual SSE connection. This map allows for multiple connections for the same user (each with a unique sseToken key) so the same user can have multiple app instances open (eg phone and desktop) and any SSE messages for that user are routed to all connections for that userID.

I also have a cron job that periodically removes any expired tokens from the pending map (ie where a GET was issued but the following EventSource() was not, for some reason).

In the JS app, by separating the creation of the SSE connection from the initial authentication process, I have the ability to create multiple authenticated SSE connections "on demand" (or not at all).

I can't think of any gaps in that approach that could breach security, but if anyone can, please let me know!

Thanks for the other contributions that helped me solve this.

Murray