Hi Greg, and welcome to the forum!
Short answer: No, not yet
Currently the common solution is to have a separate identity service/provider, such as CoreOS Dex, or an Identity Server instance, or some other solution, that issues a JWT bearer token on successful login. This token, stored in a cookie, is then used to authenticate towards a Resgate auth service. But as you say, that identity service is a dedicated web service.
That said, there are ideas for having Resgate setting cookies, but we’ve yet to decide what sort of implementation would be best.
Proposed header response
One idea (the main one at the moment) is to extend the RES Service Protocol’s Auth Request to allow a header response (instead of a result response or resource response).
This header response would only be recognized when returned from a headerAuth request, and the headers would be set set in the response to the client’s HTTP (or WS) request. So in addition, the headerAuth configuration would be extended to be used for both HTTP and WS connections, and not just HTTP (RESTful) ones.
This would allow the service configured in the headerAuth field to set cookies, and other headers, if needed.
Not sure that would cover your use case though. You’d probably want to be able to set the cookies from a RESTful POST login request?
The more feedback I get, the better a choice I can make