The best way to protect a private web application behind a login page

I'm developing a private web application on apache where all the content (documents, javascript, multimedia...) has to be protected under a login page. Also, probably, there will be different user levels that will be able to reach, or not, different areas of the application. But I think this last point can stay in a secondary place for this question.

First of all, I assume that php sessions are the best (or at least a good) option to protect an application behind a login page. (Tell me if I'm incorrect, then maybe we should reformulate the whole question).

I'm trying to read all the documentation I can. But there isn't a lot and some of it is old and I don't understand this. Protect server content (not only .php files) with login is a very common practice and I thought it would be much better documented. Anyway let's look for some examples:

1. Option 1 (10 years old): Use rewrite engine to call a php script that modifies the URL to a secure one if the user isn't logged. If the user is logged the script forwards the URL and apache continues as usually and serves the file. On the one hand I thinks this should be fast as we let apache do it's job, serve files. On the other hand there is only one instance of the script so this could be a bottleneck. There is a reason to have only one instance that there is running all the time?
2. Option 2 (10 years old): Skip the use of apache rewrite engine and use directly a php loader that gets the desired URL from a query string. I think that we could have two prolems here. First of all is that this method isn't transparent for the client, since the URL of the resources will need to have the "host.com/phploader?url=path/to/resource.extension". This could be a problem for example if front end is SPA developed from a framework CLI. And in the second hand that we will be serving the file from php, that I supose that will be slower than from apache and we will have to set manually the response headers like content-type. But since the script is executed on-demmand I suppose that there won't be the 1-script-instance bottleneck.
3. Option 3 (1 year old): Combination of the two previous. It uses the apache rewriteRule, but the file is readed from a php executed readed on-demmand. So it should be transparent and without the 1-instance bottleneck, but the file is processed in PHP.
4. Option 4 here & here (10 years old): The use of the X-Sendfile header to indicate to the server which file to serve. Theoretically the serve work here is done by the web server (but then I don't know why in the second link they place the header "Content-type: application/octet-stream"). A PHP script should still be called in order to check if the user has the right permissions and return the safe path to the file that has to be served.
5. ...

What I would like:

1. As you can see I'm not an expert in the matter. I think that it would be very interesting if you could correct me errors in the observations of the previous examples. This would help me and everyone that reads the question in the future.
2. Complete the observations with points that I have missed out.
3. Expand the list with new ways to protect the server content behind a login page.
4. In general, compare the different mehtods to find the best option nowadays to protect the server content.

I will edit the question with all the improvements.

Best regards and thanks for your time,

Héctor