KeyCloak should be used as auth server for my users?

Question

So I want to have single sign in, in all the products using a auth server but that's not only for employees, keycloak should be used to that like auth0?

Answer 1

There are also some advantages to Keycloak:

Keycloak is also available with support if you buy JBoss EAP (see http://www.keycloak.org/support.html). This might be cheaper than the enterprise version of Auth0. If you want to use custom DB, you need enterprise version of Auth0 anyway.

Keycloak has features which are not available in Auth0: Fine-grained permissions and role-based access control (RBAC) and attribute-based access control (ABAC) configurable via web admin console or custom code or you can write yuour own Java and JavaScript policies. This can be also implemented in Auth0 via user rules (custom JavaScript) or Authorization plugin(no code, less possibilities). In Keycloak you can do more without code (there are more types of security policies available out of the box e.g. based on role, groups, current time, an origin of the request) and there is a good support for custom developed access control modules. Here some more detailed research would be interesting to compare them.

Keycloak also offers a policy enforcer component - which you can connect to from your backend and verify whether the access token is sufficient to access a given resource. It works best with Java Web servers, or you can just deploy an extra Java Server with Keycloak adapter which will work as a gatekeeper and decide which request go through and which are blocked. All this happens based on the rules which you can configure via Keycloak web interface. I am not sure such policy enforcer is included in Auth0. On top of that, Keycloak can tell your client application which permissions you need when you want to access a given resource so you do not need to code this in your client. The workflow can be:

1. Client application wants to access resource R.
2. Client application asks Keycloak policy enforcer which permission it needs to access resource R.
3. Kecloak policy enforcer tells the client application which permission P it needs.
4. The client application requests an access token with permission P from Keycloak.
5. The client makes a request to the resource server with the access token containing permission P attached.
6. Policy enforcer which guards the resource server can ask Keycloak whether permission P is enough to access resource R.
7. When Keycloak approves, the resource can be accessed.

Thus, more can be centralized and configured in Keycloak. With this workflow, your client and resource server can outsource more security logic and code to Keycloak. In Auth0 you probably need to implement steps 2,3,6 on your own.