> Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.)

How is this more extreme or more cumbersome than deleting an admin account?

For that matter, you could also just give admins a separate admin account even if they are also users. When I worked in "IT support", I had a separate admin account even though I had a user account in the same system.

You probably already have a separate system that is regionally and logically separated from your application to control access to company resources.

The argument seems to be that the logical separation is not desired. But that implies that if I were an employee of Google, I should have a specially flagged Google account. And if I were to leave, I would lose that flag. Which means it should probably not be a simple flag, anymore, but a date gated property which may go off an on several times.

And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts.

> You probably already have a separate system that is regionally and logically separated from your application to control access to company resources.

The separate system your company's employees are tracked is is also likely not integrated with your app database's auth system. I kind of doubt that the various Postgres/MySQL/Whatever databases at Google have accounts in them for all of Google's employees who might need access. Instead they build more tooling on top of the same accounts the app uses to access the DB. Or maybe they create JIT accounts for admin functionality. As it stands today, though, most places don't use the DB auth at all really.

> But that implies that if I were an employee of Google, I should have a specially flagged Google account.

No. You have two accounts if you work at Google. Your personal account is not your corp account. That doesn't mean your corp account doesn't exist in the same systems as your personal account, though.

> And already, that sounds more complicated than just keeping your application accounts distinct and completely separate from your organizations accounts.

Maintaining two entirely separate auth systems does not sound less complicated to me.

I wasn't planning on really diving on this. However, two scenarios easily come to mind. Either selling a product to another company, or getting acquired. In either case, it would be nice to not have to merge two identity management systems just because corporate structure changed.

You're arguing for a separation of customer and admin accounts. These scenarios are both easier if admin and user are rolled together. If administration is tied into your corporate user system, then transferring a product means it's a pain to enable administration in the destination environment.

What you're actually arguing for is keeping app auth separate from corp auth. And that's pretty reasonable, but app admin is app auth, and must move with the app.

More generally, though, anyone buying your app/company will want it integrated with whatever auth they already have anyway, so you can look forward to a big user migration regardless.

Apologies, I was always arguing for a separation of corporate and customer accounts. My assertion is essentially that all administration of the application is done by corporate users, not application users.

Now, it is not uncommon to actually do this in three parts. A set of users that covers administration. Often made by tools that guarantee corporate level access to these accounts. And then a separate system built on top of them that does the application.

If you have truly "admin" users in the system; then yes, they should be separate from corp. And should be a flaggable part of a normal user's account. Mixing these with who can create the tables that are required for the system to run seems awkward, at best.

Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no?

> Consider, why not support all users being able to just login to the systems that run the application? It is ultimately the same argument, no?

I don't know what this means.

I don't think there's a good argument for having multiple auth systems in general, much less three. It's a lot of redundancy for little reason. It ends up complicating every app as they end up needing to support multiple systems to support both end users and administrators.

I wouldn't be surprised to find that Google has a single auth system for all users, including employees, and that they've wired up their databases to honor the single auth source.

My point is this doesn't end at the database. So, you can successfully let the database manage users and access permissions to the data in the database. But then, why not let the operating system that the database is running on control that?

And how is that a different argument than what you are proposing here?

All I was saying is that we already have auth systems and don't use them. The DB has auth. As you noted, your OS has auth. And yet we insist on reimplementing auth for our users again and again (often with terrible flaws). It does feel like something is wrong with this.

> Or, would you rather swap a regular user entry into and away from a maintenance role when you hire/fire someone? (Certainly doable, but seems extreme.)

How is it extreme; granting or dropping permissions to a particular Role for one user account is certainly not more extreme than dropping or addin a user account in that situation, which is the alternative.

> You also gain the ability to severely lock down destructive permissions to the database behind fairly rigid authentication rules.

Actually, no, you don't, because multiuser RDBMSs (well, most of the commercial ones, plus Postgres, and I'm pretty sure Firebird; MySQL/MariaDB may be weak here, they often seem to be in things that I'd like to say are generally true of RDBMSs) built in security and auth systems already give you this.

It seems extreme to base my user account of a product on my employment status. Too much that could go wrong, when you could just make your application completely independent of your organization.

My point is that there is not a single user of my applications that has the ability to drop tables from a database. In your world, there would be some. But again, why? Why should any given user of GMail, for example, be able to delete any accounts on GMail? I can see why an employee of Google would be able to. But why a user of GMail?

Newest web vulnerability: pivot your way into a job