We have a webhook that's checking, using a web-request to a separate system, if a user logging in has access to the given application. The webhook is fired on user.login.success.

There's some logic that compares the authorized applications on our end with the registrations in the FusionAuth-event-data.

When this check fails the webhook returns 401 and the login-attempt is cancelled.

This works nicely when MFA is disabled. As soon as it is enabled, though, the webhook is called after a valid MFA-code is entered, and the error message in the FusionAuth-interface says: 'invalid code'. That is entirely not the case though. The code is valid, but the webhook 'failed'.

This is the last remaining hiccup we have, UX-wise, before we can launch our FusionAuth-instance. Is there something we can do about this?

@dan Hi Dan, I don't believe I am.

To me it feels like the failing webhook cancels an otherwise successful response (since the webhook is only called on user.login.success). This event is only called after the MFA is (successfully) entered, or, with MFA disabled, when a user successfully logs in. To reiterate: when failing a MFA-disabled login it shows the Webhook-error, when failing with MFA-enabled it shows the 'invalid code'-error.

Hi Dan,

We already have an issue: https://github.com/FusionAuth/fusionauth-issues/issues/1955

But please allow me to reiterate once more, as I get the feeling the issue is now downplayed a bit to being a developer experience-issue.

1. We want a centralized / hosted authentication-solution, that we don't have to maintain ourselves. So…
2. We have a hosted FA-instance and try to use the hosted login and registration views.
3. There is an external API, though, that we Ping using a webhook for authorization purposes. This checks if application-access for a given user is still up to date with our own administration. If not the webhook returns a non-200 response and we update FA using an API-call accordingly.
4. The webhook works very nice, and will be even better as soon as we get to customize its error message, which, I believe is already on your development-calendar (https://github.com/FusionAuth/fusionauth-issues/issues/1725)
5. When the webhook fails we get a nice error message in the hosted interface that we can customize even. All is well.
6. There's one exception to this, that is when the webhook fails after entering the MFA-challenge. Then we, all of a sudden don't get the webhook-error message, that we have customized, but an error message the MFA-challenge is incorrect. Which it is not. And which confuses our users, as they try another OTP-token, or even worse: another SMS, but it keeps failing.
7. The token is not wrong. The webhook is failing. Everywhere the interface reports this correctly, except for this one, crucial, place: the entering of the MFA-challenge.

I see no way to customize this behavior, as a developer. This is not a developer experience issue, I feel, this is a bug.

@dan Hi Dan, I don't believe I am.

To me it feels like the failing webhook cancels an otherwise successful response (since the webhook is only called on user.login.success). This event is only called after the MFA is (successfully) entered, or, with MFA disabled, when a user successfully logs in. To reiterate: when failing a MFA-disabled login it shows the Webhook-error, when failing with MFA-enabled it shows the 'invalid code'-error.

@dan yes, I'd expect the message on the failing webhook (login.user.success) to be the error message that a webhook is failing, not that the MFA-code is invalid.

When MFA is disabled and the login succeeds, but the webhook fails, I do get this message.

If these error messages are consistent I can customize them to something my users will understand. Like: please get in touch with customer service, you are not authorized, or whatever.

@dan yes, the issue on Github is mine, I was unsure which platform would be best, feel free to drop one of my messages if need be. Thanks for replying on such short notice, greatly appreciated.

I suppose the behavior is correct, indeed, the login should fail.

But why doesn't the FusionAuth-UI return the notice that a webhook is failing after entering the MFA-token? It does so on every other instance. Like I said: when MFA is disabled it returns a failing Webhook-notice. When the device is already whitelisted (remember MFA for 30 days) it also returns the failing Webhook-notice. But it doesn't do that when MFA is entered and failing because of the webhook. I feel this is inconsistent.

I'm not really sure now what you mean when you ask if I can't use the message that is returned. Would you care to elaborate?

We have a webhook that's checking, using a web-request to a separate system, if a user logging in has access to the given application. The webhook is fired on user.login.success.

There's some logic that compares the authorized applications on our end with the registrations in the FusionAuth-event-data.

When this check fails the webhook returns 401 and the login-attempt is cancelled.

This works nicely when MFA is disabled. As soon as it is enabled, though, the webhook is called after a valid MFA-code is entered, and the error message in the FusionAuth-interface says: 'invalid code'. That is entirely not the case though. The code is valid, but the webhook 'failed'.

This is the last remaining hiccup we have, UX-wise, before we can launch our FusionAuth-instance. Is there something we can do about this?

The timeout is already really high (10 seconds). I can see in the logs of my webhook that I get a timeout in the api call to FusionAuth. It feels like a race condition.

We have a Salesforce-backend that administers which voluntary-roles members of our organization have. For example:

User X

• Is treasurer for department Y
• Is webmaster for department Z

These organization-specific roles we'd like to link to roles in FusionAuth-registrations.

The way we've implemented this now is via webhooks on a user.login.success – there's some logic in the webhook that fetches the Salesforce-user, links the voluntary-roles to the application-roles and updates the registration through a FusionAuth-API-call. In the following SAML or OpenID steps the roles are returned accordingly.

This works mostly fine, unless we set the transaction setting to 'all hooks must succeed'. Then the request tends to time out when trying the API-call. I can imagine some technical reasons for this (on the FusionAuth-side), as we are updating the authentication / authorization-state as it's happening. Perhaps the way we're trying to implement the (JIT) role-synchronization is not ideal, but we want to keep our source of truth contained on the Salesforce-end and this is where we're at now. I don't believe we can use connectors, as we don't have password hashes in the Salesforce-backend and in Salesforce the authorizations regularly change, so interval-synchronization of all our FusionAuth-users is also something we'd like to prevent.

Would love some thoughts, thanks in advance!