> What I always want to avoid is anyone running "create table user ( id int(32) ... )".
Hum... I have never seen a system that could ditch a user table, whatever authn and authz schema it's using. (An independent authn service only makes it more complicated, because you now have redundant user tables.)
Fair point, as most systems need to refer to users for internal relations, though with a fully outsourced solution you can get by referencing the external user ids.
As you suggest, I should have mentioned the big things to avoid are password hash and salt columns.
It's better done by some code that you (or anybody not focused on authn) didn't hack-up on half a day.
Knowing that the hashes are not stored on the database that most of your external interfaces access can bring a lot of tranquility, but you'll get some PII there anyway, so I'm not sure that tranquility is warranted.
Hum... I have never seen a system that could ditch a user table, whatever authn and authz schema it's using. (An independent authn service only makes it more complicated, because you now have redundant user tables.)
But a password column can be avoided.