How does SpiceDB compare to Keycloak's authorization functionality? If possible, how would they work together? Thanks

they're different tools with different primary use cases that make different tradeoffs. i'd say that keycloak is primarily an authn tool that can support authz through oauth scopes. SpiceDB is a centralized authorization service. you can use them together, with keycloak providing the authentication of a user, and then your application using the identity to make an authz call to SpiceDB to make a decision about whether the user is able to do something. as far as comparing their authz abilities, i'd characterize oauth scopes as "ingress" authorization, where i'd characterize SpiceDB as "centralized" authorization. an upside of ingress authz is that you can make a decision at the edge, and then downstream services have to do relatively little work to do policy enforcement - it's "does this user have this oauth scope." the downside of this approach is that the scopes ride along with every request that needs to pass the token, and as soon as you want your authz to be fine-grained, it's easy for that number of roles to explode, and then you're passing around a massive token on every request. by contrast, you don't have to worry about role/scope explosion with SpiceDB, because it's doing the work of computation when a policy decision needs to happen. you can conceivably authorize every object in your system individually, which wouldn't be possible in most cases with oauth token scopes. oauth scopes are also best suited to RBAC use cases, where you're talking about a user having a role on an object. it's much harder to express that a user should have access to a file because they have access to a folder - in SpiceDB that's encoded in an intuitive way in schema and relations, whereas in an ingress authz system you either need to write a scope for every one of the files when the user gains access to the folder, or you need to mark that a user has access to a folder and then the consuming service needs to implement its own authz logic to interpret what that means. tl;dr: i wouldn't want to use keycloak for a distributed authorization use case, even though i'd likely be happy to use it for authn. i think oauth2 scopes are great for things like platform-to-platform authorization, but i wouldn't use them inside my own system, if that makes sense. i've been wanting to write a blog post about this question for a while, actually... i should really get around to that.

Yes please. If I ever get the time to check out spice db I'd also want to use it together with keycloak

Interesting perspective, appreciate the thorough answer.

Some more 2c: Scopes and user authz are also somewhat orthogonal -- scopes authorize a token for certain actions. It doesn't actually strictly mean anything about the user other than they authorized the client who was issued this token to do an action. It's more about the session and the client than the user. Just because you have some authority , doesn't mean you want any application to use the full scope of your authority. Oauth scopes and SpiceDb work together in that sense - one authorized a client and session, the other authorized the user. Keycloak has pretty flexible authorization services specifically though they are less commonly used. In the past it's had scaling issues depending on how you used them. Lately I think the community has been exploring more of an ABAC approach that might scale better (with typical tradeoffs of db-based authz like SpiceDb vs policy based authz like OPA/many ABAC systems.)

@v.k - check out @DominikGuhr 's proof of concpet on a spicedb event listener for keycloak - https://github.com/DGuhr/keycloak-spicedb-eventlistener