You are comparing oranges and apples here, or more exactly, bricks and houses. What identifies a conversation is by definition a session. Full stop. But the session can be implemented in various ways:
- server-side data and a session id stored in a cookie (most common way nowadays)
- server-side data and a session id transported as a URL parameter (used to be common when users used to reject cookies)
- data stored in a cookie (limited to 4k) - uses fewer server resources
- maybe others...
Not all frameworks allow all session implementations.
Back to your question, from a security point of view, data that does not leave the server is expected to be harder to tamper, because it is trivial to build a custom cookie through any HTTP client library. So you should at least sign the cookie and control the signature on each pass, and if you do not want to leak internal data from the application you should also encrypt the cookie content. This, and the added limitation of 4k for a cookie size, is enough to explain why the session data is generally kept server side with only an id passed in a cookie.
TL/DR: unless you have a strong reason not to do so, my advice would be to stick to the common usage and store the user id in a server-side session: that's probably the default way for your framework...
What's the difference between storing in one versus the other for the authentication purpose?
No difference on a functional point of view because both are different implementations of a session
Which is more secure? Why?
Using a session is more secure because it will rely on a heavily tested framework or library. Server side session is more robust because cookie sessions rely on additional keys for signature and/or encryption and key management is an additional point to consider in a security point of view
Definitely session, because it is provided by your framework or library, and most security problems come from the implementation. That's the reason why security best practices recommend don't roll your own
What should I pay attention to when doing so?
You cannot rely on what you do not control, so you cannot expect that a cookie has not been tampered with client side. So you must sign the cookie at the application level with a strong and securely managed key. The internal user id is normally not relevant for the client, so you should encrypt it still at the application level, and still with a strong and securely managed key. You must add additional controls, still at the application level to make sure that the cookie (even signed and encrypted) has not been spied on from a legitimate previous session, so you must at least store the session id inside your specific signed cookie. And there may be other possible problems I have not thought about...