@purple-energy-75954 are you using Ory Kratos custom identity? https://www.ory.sh/docs/kratos/concepts/identity-schema

@swift-chef-97535 thanks a lot for the response! We use Kratos, but without custom identity atm. However, the information I want to add needs a little logic. I can imagine that you could store something in Kratos identity and that this gets returned in the JWT token, but unfortunately, it wouldn't be enough in my case. Basically what I would need is a call to another microservice. The groups (i.e. roles) I mentioned depend on the context - in one project the user might be in other groups (i.e. roles) than in another project. Therefore, I am unfortunately not able to just store one fixed value with the user's identity.

Perhaps you can combine Keto and Kratos to achieve you solution? It sounds very realistic

In theory, it sounds also very realistic for me 🙂 I suppose that it would be very easy if every user had only one key-value pair that is returned every time as part of the user's information in the token. This is also what Keycloak does, afaik. That is all good. But then, I have another challenge, where I realized last night that even Keycloak won't be able to do that (afaik): having one user in multiple clusters. A user has a different key-value pair in one cluster than in another. If the user accesses one cluster (clusters are equivalent to OAuth clients), then he should get the key-value pair

foo: bar

, but he should get

foo: bar2

for the other. Is this a realistic thing with combining Hydra with Kratos and Keto? I would need to have one endpoint of Hydra/Kratos that queries additional information during the authentication flow. I don't know how to do that though.

@proud-plumber-24205 what's your advice?

I looked a bit into the code and guess that it cannot be implemented currently. I think that we probably would have to make an additional call to an external microservice that populates the token with additional key-value pairs based on user identifier and OAuth2 client ID. https://github.com/ory/hydra/blob/master/oauth2/handler.go#L727

Hi @purple-energy-75954 I suppose you could add additional meta data to the request when doing a login flow to Hydra. https://github.com/ory/hydra/discussions/2412

Thanks @proud-plumber-24205 for replying! This metadata is something that is "stored" in the client, isn't it? That every time I make a request from the client, it automatically adds these parameters/this metadata in the request URL? I have two things I want to achieve and I state them again to be precise where this could help: 1. Not all users should be able to log in with each client. 2. I want to have custom parameters that depend on each client AND user in the response token I suppose that the custom parameters have nothing to do with 1. With 2. I fear that it won't work in a situation where the custom data depends on both client and user, am I right?

Hi @purple-energy-75954 So from reading your comments above it sounds like you want to have a Single Sign On setup but be able to track in your other application from which client the user has done the auth flow. Am I correct in assuming you have many systems (apps, servers etc) that need some Authorization to make sure when user signs in to App 1 that they cannot access App 2's infrastructure? I think it is possible to do but you would need to somewhere keep track of this. I think this will require some custom integration code from your side to disallow users logging in with any client for example. This might be able to be done through a Kratos webhook or in the jsonnet mapping when getting back an OAuth2 token. Since I am assuming you have Kratos for each app but then will use a SSO (hydra + kratos) as your OAuth2/OIDC service. @able-glass-7253 what are your thoughts on this? Since this might need some Hydra + Kratos wiring + another IAM

Thanks @proud-plumber-24205, you are right about this! I create clients dynamically and have information for each client whether users (from a central database in Kratos) can log in or not and which role they have / which group they belong to. This role / group has to be added as additional information in the token the users receive on log in from a client.

Thanks @proud-plumber-24205, @purple-energy-75954 I believe what you're trying to do is possible with Hydra. Just add the information as a claim to the ID token when processing a consent request in your consent UI. We're actively working on a Kratos update to make integration with Hydra trivial, but it is certainly doable even now, and some people have shared their solutions with the community.

Thanks @able-glass-7253! I'm glad that you are confident this is doable! I'm not very familiar with the consent endpoint though. Can I achieve the following using the consent endpoint: 1. Never show the user any UI - they are not supposed to give their consent actively, as everything that happens with Hydra, OAUth clients, etc. is within our platform 2. Have a microservice that manages the consent and can, based on the input of userID/email and OAuth client ID, a. accept or reject the login and b. put some additional information in the ID token if login is accepted? If you say that this is possible, I'll try to implement it 😉 Thanks a lot in advance!

@purple-energy-75954 I'm not sure what you mean by never showing the user any UI. The consent UI is a part of the user login flow. You linked a blogpost as a model of what you'd like to achieve. That is certainly possible by having a 'groups' trait in the Kratos user, and then turning it into a claim on the ID token when the user signs in. That's all the blogpost does. Furthermore, if you want to change the user's access when they already have a token, you'll need to put something, such as Oathkeeper, between the user and the API - that should give you all the flexibility you could possibly need

The user should get a UI for logging in of course. But I don't want the user to give any consent there. It is one part of our platform talking to another part, so all security things are handled internally. This is why users shouldn't actively have to give consent there... I think this can also be achieved with Hydra (through skipping this). Second point: Yes, I linked the blog post and all it does it specifying groups of the user. But after that I specified that I have one requirement more: The groups depend on the client as well! So each user has different groups per client. I know that this is quite an advanced use case. Would this be achievable through the consent endpoint? Otherwise I think I would have to fork Hydra and implement another call to a third-party service during the log in flow.

You should be able to use a hydrator in Oathkeeper to translate the client id (the aud claim in the id token) to the groups for that particular client As for not displaying the consent screen even on the user's first interaction with the client, that is a configuration I haven't seen yet

Okay, I understand now why the Hydrator makes sense and how it can fulfill my purpose. Thanks a lot @able-glass-7253 @proud-plumber-24205 @swift-chef-97535 @able-glass-7253 I am not entirely sure about this, but this note from the docs does sound like it is possible. Maybe I'm mistaken:

In certain scenarios (for example a special OAuth2 Client) you might not want to show the consent screen at all. In those cases you can choose to skip showing the UI and just accept the consent. Please keep in mind that OAuth2 is a delegation protocol and that it makes most sense for third-party access. Not showing the consent screen will break OpenID Connect Certification.

from https://www.ory.sh/docs/hydra/concepts/consent#previous-consent

@purple-energy-75954 Thanks for the link, that's good to know

I have finally had the time to rethink your proposal with Hydrator a bit @able-glass-7253. Afaik Hydrator comes in front of Hydra, like: user request -> Hydrator (Oathkeeper) -> Hydra (Kratos, etc.) -> token to user Unfortunately, Hydrator only knows client ID and not user ID. The groups of the user are a function of client ID and user ID though, which means that I cannot obtain the correct groups for the user for that particular client in that stage. It would be only possible if the request went to Hydrator AFTER the user logged in. That is not possible, I guess. What are your thoughts?

The setup I had in mind was to use Oathkeeper as a proxy between the outside world and the k8s api. In other words, the protected resources are the k8s apis of your clusters

Ah okay! Thanks for the clarification! I didn't think about that at all. Makes totally sense, thank you!

No problem. You'll just need to make sure the k8s api can validate tokens issued by Oathkeeper

You mentioned that you are actively working on a solution to connect Hydra and Kratos natively. What is your progress there? Are your efforts public in some way?

Yes, the development is public - you can see our progress here: https://github.com/ory/kratos/pull/2549