I would like to use Hydra as OAuth2 endpoint to authenticate and authorize access to a Kubernetes cluster, similar to what is described in https://faun.pub/kubernetes-auth-e2f342a5f269 with Keycloak. The important thing is that the JWT token returned by Keycloak contains the groups the user is member in. These groups are mapped in Kubernetes, so that Kubernetes knows whether the user is authorized to do a certain request. In Keycloak this seems to be native - in Hydra I haven't found anything about this. There is this /userinfo endpoint (as described here: https://www.ory.sh/docs/hydra/concepts/openid-connect-oidc), but I am not sure if this can somehow be used in this case. Does anyone have experience with this? I suppose I'm not the first one having this use case. Thank you very much in advance!

Hello. Ory Hydra is Oauth2 provider only. That means that it’s doing the single job and does not have any RBAC features. You can use Keto with Hydra for that case.

Thanks @damp-sunset-69236 for replying! I know that Ory is not a monolithic application and apart from Hydra, I have experiences with all other Ory components. I also know that I need Keto for this task. However, I am not sure how I can connect these two (and Kratos) in order to achieve a workflow as described in this post. The JWT token that is returned by Keycloak (in that example) is enriched with information about groups of the person. How can I achieve something similar with Ory software? I know that they are built as microservices. But I hope that this doesn't mean you cannot achieve something that is built in other products 😉 So far I always experienced Ory as the best solution available (in the cloud-native world) 🙂

You can enrich the JWT token by using Hydrator mutator of Oathkeeper, for example

Mmh okay. How would this flow look like? 1. User tries accessing the Kubernetes cluster and gets redirected to Hydra as OAuth2 Provider. 2. User logs in and obtains a JWT token 3. Hydra redirects to some URL (probably where the request came from). This would have to be intercepted by Oathkeeper though. 4. Oathkeeper has a JWT token which he should adapt. Hydrator is able to call another microservice for some information. But according to the docs, Hydrator gets the information that then can be used by other mutators. There is, of course, the id_token mutator. This mutator takes "authentication information". Can this information be the JWT token returned by Hydra together with the additional Hydrator information? I have to admit that this last step is quite unclear to me, even without going to much into the details. I hope you understand my struggles and have some ideas how I can connect these components... I describe my (ideal) workflow from a high-level perspective again: 1. User tries to access the cluster (i.e. the OAuth client) and gets redirected to Hydra. 2. User logs in and gets a JWT. His request gets redirected to Oathkeeper 3. Oathkeeper sees the request and the JWT. It asks another microservice for some more information given the details of the request and stores the addditional information into the JWT. 4. User gets directed back to the cluster.