Depending on the exact use case, there are different approaches to this kind of requirement.
1. You have two groups of users (logged-in vs. anonymous)
2. You have personalized content (menu looks different for every user depending on his permissions).
There are general integration strategies for this requirement. Let me first outline the differences in cache-ability for 1 and 2:
For 1, the menu is totally cache-able. For example, you could add a selector to the URL for user with and without permissions (menu.anonymous.html vs. menu.logged-in.html). With this approach, the application will make the decision which menu to integrate for a certain user. You would want to ensure that this mechanism is somewhat secured and can't be tampered with from the public. Please note: this can also be scaled to a certain amount of different groups (= variations of the menu) but I would keep the number as low as possible (probably a low 2-digit number as maximum).
For 2, you won't be able to cache it. You would need to cache a dedicated page for each user and that most probably will outweigh any gains achieved by caching in the first place.
Coming to the integration strategies:
Integration on Apache HTTPD/Dispatcher level For certain use cases, Server Side Includes (SSI) on web server level can be leveraged. This can be handled dynamically e. g. based on a users session, headers or other environment variables available to the web server. For permission related use cases it is usually necessary to somehow integrate Apache with the system managing the authorizations. I've seen setups handling authentication and authorization on Apache level through certain Apache modules and leveraging the resulting information in SSIs.
Sling Dynamic Includes Probably the best fit for most use cases and commonly recommended is the approach of Sling Dynamic Includes. It combines SSI (see above) in a more integrated way with AEM/Sling.
Two more things to consider:
Depending on the level of security that is required, don't just look at the links but also put access control for the actual target pages in place.
Is the header section the only place where you have links to these target places? Things may get quite complicated if there are other links to these protected pages spread across the website, e. g. content editors adding these links to regular pages.
You can create 2 different XF(Experience Fragment) one holding navigation content for logged in user and one holding the content for non-logged in user.
By default show the non logged in state content and logged in content can be shown only when you identify the user is logged in which again can be managed in multiple ways such as:
You can create a cookie when the user is logged in and when the user is not logged in or logs out, you need to remove the cookie. So based on cookie availability you can switch the content from JS. Here the complete content will be cached and the logic will be driven at the frontend.
If you don't want to go with JS approach, then you can go for sling dynamic include (SDI) and include a component which will invoke the Sling Model in backend and will provide you the dynamic path for the experience fragment with the relevant content. In this way, the whole page will still be cached at the dispatcher except the header section which is loaded using the SDI approach. The logged in or non-logged in state needs to be managed in Sling Model here.
Now coming to user validation on each request, You can set some unique value(let's say session id) in the cookie by encrypting it in AEM using the Crypto support and each time you make a call, you will need to invoke a service on backend which will read the cookie value, decrypt the cookie value and will check if it;s valid or not. If it's a valid session, it will allow you to proceed further, else you can handle the error based on your use case i.e., either you can redirect to 500 error or you can show some error message saying you have been logged out.
We had a similar requirement, to hide few links(protected links) for an anonymous user.
Our solution was -
1. Create a Sling rewriter (LinkTransformer) to find a protected link (based on cug:repPolicy node ) and add a class(link-protected--hide) and hide link by default
2. On front end side check if a user is logged in and has access to those link then remove the class link-protected--hide
The page is always same and cached.
In your case, you can specify those links from page properties and read them directly in the header (no need to create rewriter if changes are not global) and from end based on user type remove the hidden class or add the hidden classes