What is a good way to create a database for multiple frontend users (one must cannot touch other users' data)?

To give the briefest and high-levelest of fly-bys: there are two basic steps, authentication and authorization.

• Authentication answers the question of who or "are you who you say you are". Just because I claim to be Elon Musk does not mean I will be allowed in the factories or access to his riches. I need proof (a password, 2FA, etc.). Use a standard library for this.
• Authorization answers the question of "are you allowed to do this?". Let's build a twitter-esque app to explore this:

Let's have users and chirps. A "chirp" can be sent to a single user or sent publicly. To represent that let's make the chirps table have just a few things: from_user_id (the one who wrote it), content (aka the "chirp"), and to_user_id (if empty it is public, if not it's a direct message).

If I ask to see chirp 42, the authorization step needs to answer whether I'm allowed to view that chirp or not. It would probably follow just a few rules:

1. Is this chirp public? (aka to_user_id is empty)
2. Was the chirp sent to me? (aka the current_user_id that I've authenticated myself as having is equal to this chirp's to_user_id means that I'm authorized to see this chirp)
3. Was this chirp created by me? (aka current_user_id equals from_user_id)

If any of those things are true, then I am authorized to view the chirp and the app can continue with rendering it all nicely. We can think of similar rules for any other action a user might take: attempting to edit chirp 42, are you from_user_id; attempting to send chirps, have I been blocked or banned; etc.

Often it can be helpful to think of authorization in two steps:

1. Am I allowed to take this action at all (i.e. if chirper is paywalled, have I paid this month?)
2. Am I allowed to take this action against this data (i.e. I can see most other chirps, but this chirp in particular was sent to someone else, so I am not allowed to see it)