related to Eero's question above, i have a similar use case i'm trying to solve. but rather than service-specific configuration, we want to have customer-specific login options, as some of our customers want to be able to log in with their own SSO providers (e.g. okta tenant), possibly also blocking access to a password-based login. however, it looks like the only real way to do this self-hosted is to set up a separate kratos tenant for each customer, each with its own configuration for login providers. would it be possible to do this with each tenant pointed at the same database? since our application is multi-tenant, it would be best on the app side to keep the identities as centralized as possible. alternatively, is this something the ory network can support already? we would definitely consider moving to the hosted option if it would more easily support what we need

What are the issues you see when trying to set this up using only one "tenant"? This is essentially just integrating multiple generic OIDC "social log-in" providers. Not every user needs to have a credential for every social login-in provider afaik. You'll probably need to get a bit creative on the front-end to "hide" SSO links and make sure you're not exposing customer information, but on the Kratos side I guess I'm not seeing what the limitations are.

yeah, hiding the providers is the tricky part, since from what i can see in the response the UI pieces don't really tell you details of the provider that created these elements, like the ID in the config

Which response are you looking at specifically? The way I thought about it (and haven't done yet) is having it be one of those 2-page login processes. First the user enters an email, that email lets you load their Identity from the backend, and then from their Identity entry you can read what credentials they support, letting you generate the second login page with their available credentials. I'm not close to beginning implementation yet, but based on what I've seen so far it seems reasonable.

is it possible to tie available login methods to an identity? as far as i could see, the available methods are only configured at the service level, but i guess you could do it through metadata

https://www.ory.sh/docs/kratos/reference/api#tag/identity/operation/getIdentity The

include_credential

flag should allow you to view all of the available credentials. Self-service isn't needed on my end so I'm not sure how that would work/haven't thought about it

that is different than what i am trying to solve, as that only shows the currently configured credentials, not the ones that should be available to that user

I'm not sure I understand the issue then. It sounds like you want to predict a user's available authentication options before they've actually registered as users of those authentication options?

correct, yes, that's what we're doing. it's definitely just a UX choice not security related, as if a user did see the login option for another customer's SSO system, they wouldn't be able to authenticate anyway, so it's just to keep the UI from being really messy as we add more options

Gotcha gotcha, yea that makes sense. I haven't thought about it to that extent but I'd love to hear how you end up solving for it.

Maybe you could have your own backend on front of Kratos endpoints and do the filtering of the returned methods based on something like client id if you're using Hydra OAuth/OIDC. With multitenancy the configuring of methods becomes a burden as they are configured in the kratos.yml or env vars. I wonder if an API for managing methods is in the roadmap for self-hosted.