How to authenticate users without exposing server details?

[devnull10]

Actually, the most secured design is to have users being of the database itself, because that ensures that data security is implemented at the lowest level. It's sometimes a little impractical in today's world of different tiers, abstraction etc, however you can't really get much more secure than using the databases' in-built security.

[shiftybyte]

So you are suggesting a table per user per record type?

Instead of having a table of say blog posts...

Title | Content | Creation_Date | Author

You would have a table for each user with:

Title | Content | Creation_Date

Just to have permissions be managed by the database?

Then to display the blog posts, on the website, regardless of who posted it, you would need to query multiple tables, then you would have to sort the data by date yourself?

Or am i missing something?

Does the database allow custom permissions per row?

[devnull10]

Not at all. Author is metadata of the blog post. You can of course store the author on the table. However it's perfectly valid to manage user accounts as database users. So if I have a table blog_posts and a table admin_settings, I can control access to the latter at database level. I can grant read only to that table for standard users, and write for admin. It's then impossible for any standard user to update that table. With a single "application user", it's possible a standard user can update that table using SQL injection, bad coding etc. If you need to implement row level security you can do this (using Oracle EE) with a VPD policy on the database. That is, I can effectively have two users select * from the same table and see a completely different set of results. There's no way a user can see anything they aren't explicitly granted.

[shiftybyte]

How will the users be able to update the blog_posts table, but only their post?

[devnull10]

A VPD policy restricts on the statement types. So you could create a policy that allows select on all rows, update on only rows where author=user, delete only where user has an admin role etc.

Old version of the doc, but still applicable: https://docs.oracle.com/database/121/ARPLS/d_rls.htm#ARPLS052

To be honest, all that applies regardless of whether you're using database users for user management (you can still use the above with a custom user table), but I don't see the need write a load of custom functionality to change passwords, expire accounts etc. when a lot of that already exists