We have a couple of users that initially signed up with email/password and then linked SSO login for that email. Is there a way to disable the email/password login method after SSO login is setup for an account? This would also prevent users who first signed up with SSO to then later to link email/password to an SSO account. This is mostly a security thing we’d like to enforce

My team and I are also trying to implement exactly this behaviour. I've tried to do this using webhooks but they're not working and I'm still running into bugs (particularly around the fact that ORY cannot support MFA when OIDC is enabled). @magnificent-energy-493 @bland-eye-99092 do you have any ideas about how to implement this?

There is no built in solution for this, that's true. But it should work with webhooks.

I've tried to do this using webhooks but they're not working

What have you tried, what are you observing and what are you expecting, exactly?

particularly around the fact that ORY cannot support MFA when OIDC is enabled

This is not true, what's your config, and what's happening specifically?

If I have OIDC and TOTP enabled on any account/identity, this is the MFA prompt I receive (see this message from Oct 3rd). Consequently, to support seamless migration of users from email-and-password-based login to Enterprise SSO-based login, I need to remove the TOTP configuration of an identity mid-way during the registration flow. I have a webhook to do this but I get an "identity not found (404)" error when I try to fetch the identity from my webhook server. It seems like the identity ID is not available even when executed after the registration flow. So there is no clear way to update identity credentials mid-way through registration, in a way that would prevent the broken MFA screen below from appearing. Also, this is Jsonnet for the body of my POST request to my webhook server:

func(ctx) { identityId: ctx.identity.id }

I have a webhook to do this but I get an "identity not found (404)" error when I try to fetch the identity from my webhook server. It seems like the identity ID is not available even when executed after the registration flow.

Is your webhook set to "parse" the response from it?

No. I was running into a different error when doing that. The docs also say:

The webhook is triggered after form submission but before the identity is stored. It can modify identity data or interrupt the flow. The identity ID is not available yet, and registration may still fail, especially if an identifier is already in use.

So the identity ID would not be available if the response was being parsed, right?

yes, that's correct. But the identity's data would also be available in the webhook's Jsonnet snippet. Why do you need to fetch the identity?

To delete the TOTP credential for the identity.

This is a bit out of scope for this thread, please open a bug report on ory/network and make sure to include all necessary configuration. We can take a look there.

Update here: I'm able to get the webhooks working now and remove the TOTP config. Though I will reproduce the issue later when I have time and submit a bug report.

Thanks a lot @bland-eye-99092 for letting me know it is possible. I hope it is not too much to ask for to get some links to documentation for the endpoints which we could use to achieve this?

@fast-eve-41839 https://www.ory.sh/docs/reference/api#tag/identity/operation/deleteIdentityCredentials this should be the API you are looking for

@magnificent-energy-493 What do you suggest in terms of error response when someone tries to add password credentials when you already have oidc?

"messages": [
                    {
                        "instance_ptr": "#/traits/email",
                        "messages": [
                            {
                                "id": 101,
                                "text": "Adding password based login when you have stronger login method is not supported",
                                "type": "validation",
                                "context": {"value": "not supported"},
                            },
                        ],
                    },
                ],

Specifically on the

instance_ptr

there

I am also very interested in this thread. The deleteIdentityCredentials documentation explicitly says you can't use it to delete passwords. Having old passwords lying around that cant be changed or removed, but can be used to login is suprising to me.