I’m developing a web service that have following structure:
- Web Server: this is implemented with NextJS which do Server-Side Rendering and serve server-side rendered webpage data to Client.
- API Server: and this one is implemented with NestJS. Clients will send graphql queries/mutations to this server.
- Client: any clients can visit my web service and sign in (or sign up)
and I want to implement authentication feature for my web server, but problem is came up here. how can I share the auth data between Web Server, API Server, Client? if you signed in on your own browser, eventually a signing request will be sent to the API server.
but there’s literally no way to know whether the client is signed in or not from Web Server. I mean, auth data (whether if user has signed in or not) will be stored only at API Server.
I had searched and spent a lot of time about this and I’ve got an answer that I have to use JWT Token but there were several ways to store it:
-
Storing it on clients’ web storage: I don’t think this can be an answer since the
Web Servershouldn’t able to get clients’ web storage data. this means SSR (server-side rendering) wouldn’t work well. -
Storing it on
Cookie: this is bad too. because we send a signing in request to theAPI Serverthat will be on different container (or server) and domain. we cannot set cookies from different domain with proper way. and if we get token and store it cookies directly from client side (setting cookie from javascript), It will be really huge security issue since attackers can take users’ token with XSS. -
Using
Cookiebut set from other subdomains with specifyingDomain: we can specify domain for setting cookie. as far as I know, a response fromapi.example.comcan set cookies forexample.comwith specifyingDomainproperty ofSet-Cookiesvalue. read this
yeah, method 3 seems pretty neat to have but I absolutely don’t know that setting cookies from another sub-domains will cause big security hole. my web service will process about users’ money so security issues will come very critical.
someone I know advised me that I can use reverse proxy with paths not domain. I mean, if API Server was serving on api.example.com, we can serve it on example.com/api/* so now we can share the cookies between all the server and client. but we should store cookies on web storage too since cookies will be flagged as HttpOnly. this will cause increasing complexity of development.
In this case, which method will be the best answer for my case? are these methods I’ve mentioned above are really safe to do?
So if I understand it well, I think the third approach with a reverse proxy to paths may be enough to share the authentication in the domain (in the short term), like you have an API and get session token in the same application but it adds a ton of complexity.
Nevertheless, you may want to step ahead in your development and keep only one authentication so, I don’t know if you are using some OAuth authentication process, or is just as simple as user and password, but in case you are using oauthv2, (you can set up your own server with passportjs) you can use Single Sign-On (SSO), and you redirect your user where the application lives (example: POST sso.example.com) to get session JWT and redirect to the application so the cookie set into the right domain. Also if you need information about the user you make a POST request to sso.example.com to get details of the logged user.
Note: be careful to encrypt the cookie and DO NOT send user information inside it, better to make another call to fetch the user’s information.
Some useful links with other industry techniques:
- Session Sharing
- Nodejs SSO