Cookie stores authentication information, such as roles. The server can generate cookie and verify whether it is a cookie produced by itself through key. There is no cookie or the cookie generated by the server is not logged in. When you encounter permission pages, you can determine whether to allow release by parsing the information in cookie (that is, role). There is no need to access important user information. It is recommended to study jwt and stateless authorization

can be saved, but it is useless to save. Do you think this id is a legitimate login user when customers deposit which id?

this should be verified with the server Session, because the local cookie can be modified at will, and important user information (such as passwords) should not be stored locally

your question is actually two questions:
1 is the way of cookies and session secure? Security, otherwise there is no other way for users to record user status. So after a successful login, users generate session on the server side and cookies on the client side, so that they can contact each other and bring cookies to find the session the next time the user requests the server side from the client side. But you need to use a random or UUID that is not easy to identify as a cookies client, and then manually bind its relationship with session. Of course, it will be safer to use HTTPS.
2, some interfaces need some interfaces, and you can use interceptor to control fine permission verification through API's mapping.