Na maioria dos aplicativos da Web, o modelo de segurança é definido na camada de lógica de negócios, não na camada de dados.

Por exemplo, minha capacidade de editar uma postagem no Stack Overflow não é controlada pela minha capacidade de ler/gravar na tabela "posts" - na verdade, você provavelmente nem poderia projetar um esquema de banco de dados que permitisse implementar o nível do banco de dados segurança neste nível. Em vez disso, há uma camada de lógica de negócios que compara meus privilégios com a ação que estou tentando executar (suponho); a segurança é implementada na camada lógica de negócios.

Francamente, não vejo quase nenhum benefício em passar credenciais para a camada de banco de dados - se de alguma forma eu tivesse ignorado a lógica de negócios para controlar quem pode editar postagens SO, os controles de "leitura/gravação" do banco de dados não impediriam isso e a auditoria não t realmente ajudá-lo.

Vejo MUITAS desvantagens - principalmente o fato de você dividir sua lógica de autorização em duas (lógica de negócios e banco de dados) e introduzir todos os tipos de modos de falha divertidos com contas de sincronização em sua camada de lógica de negócios e camada de banco de dados (usuários alterando suas senha ou sair do site). Não consigo imaginar como você testaria e depuraria tudo isso com sensatez - o que acontece se um usuário final receber um erro relacionado aos privilégios do banco de dados?