I have a client who’s pushing back on my recommendation to let Keycloak have its own dedicated database. They’d rather use a single shared database for both Keycloak and their LOB application(s). I think they’re just feeling very resource constrained, on both hardware and humans, and so adding in a whole other database feels like a huge undertaking for them, enough to trump my “in my professional opinion” and “best practices” counsel. Which is fair enough.
I’ve done a bit of Googling, but I’ve not come up with a nice, easy-to-read recommendation for a separate database for Keycloak, or for any auth system in general. So I though I’d check if folks here could point me at anything.
I don’t know of such a guide, but the argument would not be for separate databases, running on a separate machine/vm, but just a logical separation in named databases, which could be running on the same machine/vm and database server process. And, in the case they’re using PostgreSQL or Oracle, they could also have the Keycloak and application databases running in separate schemas to enforce further isolation. The only argument (good) argument I can think of for running on a separate machine/vm is for resource contention, in the case they’re really slamming their application database.
I agree that resource contention is an issue, eg that some runaway code on the application side would then start affecting auth. Security is another, in that it’s easy to forget that any superuser-type accounts intended for very broad app permissions would also allow access to the auth database, Network security would be another … you can have a very secure database when it only needs to allow access to the auth service and to nothing else. Maybe other things too, eg stronger encryption for data-at-rest, since performance isn’t as critical.
All of which can be achieved in a single database, using the practices you alluded to. My concern is that it’s easy for an overworked, field-promoted ‘DBA’ to get those subtleties wrong, whereas you can give auth its own db instance and never worry about it.
But, I can see the appeal of simply getting the isolation right, and then enjoying the benefits of one less database.