Is it possible to configure multiple different applications that have different requirements for authentication with the self-hosted kratos? For example we would have

application1

that allows access with password and then

application2

that requires password and totp and then maybe

application3

that can be accessed only with oidc. Couldn't find anything related to this in the documentation.

this is actually something i'm looking into as well, and as far as i can tell this is not possible with a single kratos instance. i was hoping it could be done through identity schemas, but because the auth mechanisms are configured on the instance itself, you would need different kratos instances with different configurations to set up different authentication mechanisms. so i'm now considering the option of using our UI layer to limit the login mechanisms appropriately.

I also looked into identities to get this configured, but seems like there can be only one identity schema "active" and others are for supporting the old schema when updating to a newer schema. I don't know how it would behave if you for example remove password credentials when updating your schema. Probably it would mean that the login would not offer password as an option anymore. Something like that could be probably achieved with the

aal

attribute when creating the login flow in the client application side but that would be only defining if a second factor is needed and I'm not sure if it would be enforced. I think password and oidc are considered as aal1 so this wouldn't help defining only password for some and oidc for other. Need to play around with that a bit to see how it works.

i believe any number of them can be active, but only the default will be used for self service registration flows, other identities would have to be created through the API

I think that also the login page is drawn based on the active identity schema.

yes that seems true as well

I wonder how that aal2 would be enforced? I know it's possible to enforce it on the

whoami

and

settings

flows in kratos and those would return 403 or similar if if the session is not aal2. Probably you would need to build the logic in the application to enforce it.

yeah, the more i look into this the more i'm thinking it will require separate kratos instances, as even just to build the UI it looks like the flow response gives the information you need to directly build HTML elements, not info about the flow that you would use to build your own UI however you want. so i don't see any good way to be able to filter those elements, especially if you have multiple configurations of the same social provider that need to be filtered differently, i suspect they will generally look the same.

Maybe it's possible to use the native client self service API endpoints to have more control over what to show on the login page.