Is there a way to have Resgate set cookies?
it seems like the only way to authenticate RESTful endpoints for Regate is if a cookie is set from a separate service.
Looking at the authentication examples it looks like non Resgate services are setting a cookie for the authentication
is there a way I can have my auth.login.user service respond in a way that sets the cookie auth for RESTful endpoints?
I don’t want to have to run a dedicated service just for the purpose of setting a cookie.
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.
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 
Best regards,
Samuel
Howdy, I’m happy to be here.
Thank you for your work on Resgate, it seems like a really great protocol so far, I’m starting to think it should be a staple for anyone working with micro services and event based systems. I’ve learned a lot in the short time I’ve been playing with it.
I’ve seen many poorly designed systems masquerading as event based, micro service architectures. It’s refreshing to see a protocol that encourages better design.
Regarding the cookies, it sounds like your idea should do the trick. It seems like a natural fit for the protocol.
I’ve been playing around with the session resume example; setting the relogin key in localstorage makes me cringe because of the security implications. If resgate could simply handle setting the cookies and set one of them with the http only flag that would be ideal especially if it could cover both RESTful and the websocket.
I’d love to be able to tell the auth service to set the relogin token as an http only cookie and handle that with auth requests.
Glad to hear
True, using local storage would be dangerous if someone succeeds with an XSS attack. There are counter measures that can be added to make it more secure, but it is still a vulnerability. httpOnly cookies are more secure, but since they can only be set when establishing the WebSocket connection, not afterwards, they will never be used for password logins done over WebSocket in a call request.
So, the initial login (be it password, oauth2, or something else) would still have to be over HTTP(s). And for now, it would be a separate web service.
But the mentioned header response proposal could solve this.
I will spend some more time considering it, to see if there are other caveats to the idea. It shouldn’t take much effort to implement, and it would be backwards compatible with older services and clients. So, it is mainly about having thought it through.
Mmm, and I should consider re-writing that sessions article.
/Samuel