The key requirement you mentioned now: the user needs to be logged in.

So, the next question is: how do we know the user is logged in. It can't be just a simple cookie because that could be faked (I could add "LOGGED_IN=1" without the site authorizing this), and therefore there is no security at all. Maybe added obscurity :-)

What you need to do is issue a cookie that can only have been created by NGINX, e.g., something like a string "{user}/{checksum}", where {user} is the id of the logged-in user, and {checksum} is an HMAC of a secret only known to NGINX and that user id. In consequence, without knowing the secret, nobody can fake this cookie. If NGINX gets the cookie, it can determine the HMAC of the user id and compare against the checksum provided, in order to check the validity of the request.

The HMAC computation and validation can quickly be done with a few lines of Javascript, and would even allow for some sort of single sign-on across all services capable of using these functions (also in other NGINX instances knowing this secret). Maybe you want to add some form of expiration to such cookies.

The classical way, however, is to use https and something like a basic authentication (auth_basic directive), and require valid authentication for those URIs referring to protected files. If your authentication scheme is a bit more complex, you may want to use auth_request or some form of initial login plus a secured session cookie as described above. Essentially, this principle (with JWT) is also used by more novel schemes such as OpenID Connect.

Let's see if this helps you further.