To elaborate, if I have group G1 having user U1 part of group and add G1 under Closed User Group from page properties, it should only allow U1 to login to the restricted page. However, it allows other users (U2, U3 for example) as well to access CUG restricted page which is not an expected scenario. To summarize, it allows all valid users to login to the CUG restricted page. To add, I am testing from publisher side, so no dispatcher changes would come into affect here.
Adding my update for the issue for someone who visits this.
So, CUG will allow the users (U2, U3) to login and will not send error response for "authentication". And it will set the login-token cookie. However, since the user is not authorized to view the content for the page, it will show up 404 page. In your case, if you have setup a default 404 page, it will show up content from that page after setting the login-token cookie. Now since the default 404 page content might be part of /apps/<your-site>, you will need to give read permission (to U2 and U3, make sure you don't mess up ACLs on publishers) to that path as well (pretty much the issue I had where the 404 page content was not being rendered properly).
To summarize, even if the user is not "authorized" to view the content since it is not part of group G1, it will set the login-token cookie but render 404 page. If the user is part of group G1, it will show up the content of the page. I had all the required permissions set from /content/ but read permission under /apps/<site> were missing which is holding some default designs.