FusionAuth
    • Home
    • Categories
    • Recent
    • Popular
    • Pricing
    • Contact us
    • Docs
    • Login

    Failing webhook on user.login.success gives weird feedback

    Scheduled Pinned Locked Moved
    Comments & Feedback
    3
    10
    2.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      appeal
      last edited by

      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?

      danD 1 Reply Last reply Reply Quote 1
      • danD
        dan @appeal
        last edited by

        @appeal Looks like you posted an issue here: https://github.com/FusionAuth/fusionauth-issues/issues/1955

        It sounds like the behavior is correct (the login should fail), but the message is incorrect. Is there some reason you can't use the message that is returned?

        --
        FusionAuth - Auth for devs, built by devs.
        https://fusionauth.io

        A 1 Reply Last reply Reply Quote 0
        • A
          appeal @dan
          last edited by

          @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?

          danD 1 Reply Last reply Reply Quote 0
          • danD
            dan @appeal
            last edited by

            @appeal

            Hiya, let's continue the conversation here and we can always move over to GitHub if needed.

            So just to repeat back what I understand:

            • everything behaves correctly when MFA is turned off for a user
            • when MFA is turned on and the webhook fails, you are getting an inappropriate error message

            The error message you are getting in the second case is 'invalid code' and you want to change it to a more appropriate message.

            Is that correct? Or did I miss something?

            --
            FusionAuth - Auth for devs, built by devs.
            https://fusionauth.io

            A 1 Reply Last reply Reply Quote 0
            • A
              appeal @dan
              last edited by

              @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.

              danD 1 Reply Last reply Reply Quote 0
              • danD
                dan @appeal
                last edited by

                @appeal

                One more q. Are you able to distinguish between the case when the webhook fails and the case when the user truly enters the wrong MFA code? It seems like you would not be able to, but just want to confirm.

                --
                FusionAuth - Auth for devs, built by devs.
                https://fusionauth.io

                A 1 Reply Last reply Reply Quote 0
                • A
                  appeal @dan
                  last edited by

                  @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.

                  danD 1 Reply Last reply Reply Quote 1
                  • danD
                    dan @appeal
                    last edited by

                    @appeal Ah, okay. This seems like it is at least a developer experience issue that could be improved.

                    Can you please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues

                    Feel free to reference this forum post.

                    --
                    FusionAuth - Auth for devs, built by devs.
                    https://fusionauth.io

                    1 Reply Last reply Reply Quote 0
                    • A
                      appeal
                      last edited by appeal

                      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.

                      1 Reply Last reply Reply Quote 0
                      • H
                        herringburdensome
                        last edited by

                        This post is deleted!
                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post