We are building a project from scratch, and we are considering a separate, custom DB to be loosely coupled and not dependent on Keycloak.
Are there drawbacks to using the Keycloak database vs a custom one?
Is it highly customizable with adding and removing columns/changing the schema?
What are you referring to when you talk about “keycloak database” and “custom one”?
Keycloak can run with an in memory h2 database. It is not suitable for production use.
Keycloak should have its own database/schema in postgres/mysql/oracle…
Then your application should have its own database/schema in whatever DBMS you want to use.
I don’t see any overlaps here.
So you are saying that Keycloak is supposed to use one database, and my application is supposed to have its database. So, I will end up with two entities per user. This seems like a terrible design. Also, why would User Storage Providers exist if there are supposed to be two databases?
So you are not only talking about shared databases but also a shared database model?
Well…
Nothing stops you from doing that. Table name prefixes exist, liquibase surely can be instructed somehow to have no collisions. Keycloak by designs is extensible so you could store your information in the database or implement a custom user storage SPI to use your own model.
It probably will work. Keycloak is extensible and flexible and can be used for a lot of things not necessarily adhering to the ideas of SSO or more precisely OIDC or SAML.
The question is, should you?
It would produce very tight coupling between the app and the authentication provider while they are intended to be two very distinct instances.
OIDC separates authentication and authorization from the application.
If you consider Keycloak as your authentication provider, which handles authentication and provides your app with authorization information you suddenly have very different requirements towards each and subsequently the entities they are supposed to store.
They are supposed to do very different things.
Another note regarding user storage providers. They are not bound to a single database. You could implement one which looks into an entirely different kind of datastore (another DB, REST API, LDAP, …) it allows you to connect to different external (probably legacy) systems and integrate them into your authentication infrastructure.
At the end of the day, nothing stops you from doing something like that, but why would you want to use keycloak then in the first place.
Either you buy in on the OIDC way of doing it, or Keycloak is probably not the tool for the job.
That was an excellent and straightforward answer. I appreciate that!
I agree that a tight coupling of our application and Keycloak is not desirable.
We will probably go for using separate databases for Keycloak and our application.
Have you seen the User Storage SPI? One of my customers brings its own oracle user store, another brings its own postgres user store. These are independent of the Keycloak tables and access via a JAR I deploy that implements the SPI
To reiterate, it is best practice to store Keycloak users/credentials in one table, and your users for your application in another. Is it ok to have them on the same mssql server?