breakfix: MFA-related issues

[alperensozer]

Describe the issue

I hit two MFA-related issues while testing local auth with caddy-security:

Dockerfile ->

FROM caddy:2-builder AS caddy_builder

RUN xcaddy build --with github.com/greenpau/caddy-security

FROM caddy:2

COPY --from=caddy_builder /usr/bin/caddy /usr/bin/caddy

1. Frontend bug on MFA enrollment page
   On the MFA enrollment page, clicking the Add button does nothing.
   No network request is sent.
   In the browser console, I see this error:

   An invalid form control with name='label' is not focusable

   It looks like the form contains a required label field that is hidden or otherwise not focusable, so HTML form validation blocks submission before any request is sent.

   As a workaround, manually setting a value for the hidden label input in DevTools makes the form submit successfully, for example:

   document.querySelector('input[name="label"]').value = 'Auth'
   

2. MFA prompt appears twice
   After MFA is configured, I am prompted for OTP twice during login when require mfa is enabled.
   From the logs, I can see these checkpoints:

   • Authenticate with password
   • Multi-factor authentication app
   • Multi-factor authentication

   This results in what feels like a double MFA flow.
   When I remove require mfa, the flow becomes normal again and I only get a single OTP prompt.

So there seem to be two separate problems:

• a frontend/UI bug on the MFA enrollment page (label field)
• a duplicated MFA challenge flow when require mfa is enabled alongside TOTP app authentication

Configuration

Paste full Caddyfile below:

{
    order authenticate before respond
    order authorize before basicauth

    security {
        local identity store localdb {
            realm local
            path /etc/caddy/users.json
        }

        authentication portal mainportal {
            crypto default token lifetime 3600
            crypto key sign-verify {env.JWT_SHARED_KEY}

            enable identity store localdb

            cookie domain alperensozer.com
            cookie path /
            cookie lifetime 43200
            cookie insecure off

            trust login redirect uri domain suffix alperensozer.com path prefix /
            trust logout redirect uri domain suffix alperensozer.com path prefix /

            transform user {
                match origin local
                action add role authp/user
                require mfa
            }
        }

        authorization policy mainpolicy {
            set auth url https://auth.alperensozer.com
            allow roles authp/admin authp/user
            crypto key verify {env.JWT_SHARED_KEY}
        }
    }
}

auth.alperensozer.com {
    route {
        authenticate with mainportal
    }
}

proxy.alperensozer.com {
    route {
        authorize with mainpolicy
        reverse_proxy wgclient:5800
    }
}

Version Information

Provide output of caddy list-modules --versions | grep -E "(auth|security)" below:

1.1.62

Expected behavior

1. On the MFA enrollment page, clicking Add should submit normally without requiring a hidden label field workaround in the browser console.
2. When TOTP app MFA is configured, login should require only one OTP challenge.
3. Enabling require mfa should not introduce what appears to be an additional MFA checkpoint on top of the TOTP app challenge.

Additional context

• I am using local identity store (users.json).

• MFA enrollment succeeds only after manually populating the hidden label input via DevTools.

• Browser console error during failed enrollment:

  An invalid form control with name='label' is not focusable

• Logs during login with require mfa enabled show multiple checkpoints, including both:

  • Multi-factor authentication app
  • Multi-factor authentication

This is what makes the login flow ask for OTP twice.

If helpful, I can also provide:

• browser screenshots of the MFA enrollment page
• console output
• relevant auth/security logs

[greenpau]

@vnykmshr , could you please take a look.

Separately, need to revisit challenges PR.

[greenpau]

@alperensozer , please do provide browser screenshots and anything else relevant in troubleshooting.

Also, remove “require mfa” from the config and see if the issue persists.

Did you configure MFA through Profile UI?

[alperensozer]

As for MFA, yes — it was configured through the Profile UI.

Initially, I set it up with “require mfa” enabled, and MFA (OTP) was configured via the UI during the first setup.

When I noticed that OTP was being prompted twice, I checked the logs and it seemed like both the app and another layer were triggering it. I then removed “require mfa” from the config, expecting it to stop the flow.

However, since MFA is still marked as enabled under users.json, it continues to prompt. After removing the setting, it asks only once, whereas before (with “require mfa” enabled) it was prompting twice.

Below is a log entry after removing “require mfa”, showing a successful single MFA checkpoint:

{"level":"info","ts":1776765385.074727,"logger":"security","msg":"user passed all authorization checkpoints","session_id":"...","request_id":"...","checkpoints":[{"name":"Authenticate with password","type":"password","passed":true},{"id":1,"name":"Multi-factor authentication app","type":"totp","passed":true}]}

[alperensozer]

This is the behavior during the initial setup when I click the “Add” button. At that stage, MFA was being configured via the UI with “require mfa” enabled.

From the browser network tab, I observed that no request was being sent when clicking the button — it wasn’t triggering any network call. I was able to work around this by manually setting the label field via the console:

document.querySelector('input[name="label"]').value = 'Auth'

After doing this, the button worked and the request was sent successfully.

Also, the QR code shown there appears to be obsolete anyway.

[vnykmshr]

@greenpau

On the duplicate MFA prompt: For a user with a single TOTP token registered, the identity store emits the specific totp challenge. require mfa appends the generic mfa challenge. Dedup compares as strings, both keywords survive, and both dispatch through the same MFA path, so the user enters the same TOTP code twice. Matches the log excerpts in the thread: three checkpoints with require mfa, two without.

We can drop the generic mfa when merging challenges if a specific MFA keyword (totp, u2f) is already present. For users with no MFA registered, the challenge list has no specific keyword, so the generic mfa stays and the enrollment path fires as before.

Can PR with tests covering single-method (totp, u2f), dual-method, and zero-MFA users. Holding for your direction.

Enrollment Add appears to be a frontend issue, separate from the challenge-merge issue. Needs a closer look before suggesting anything.

[greenpau]

From the browser network tab, I observed that no request was being sent when clicking the button — it wasn’t triggering any network call. I was able to work around this by manually setting the label field via the console:
document.querySelector('input[name="label"]').value = 'Auth'

@alperensozer , what do you think needs to be changed in the file below?

https://github.com/greenpau/go-authcrunch/blob/main/pkg/authn/ui/page_templates/basic/sandbox.template

[alperensozer]

I was not able to fully test a proper template patch yet because I could not locate the editable source template in the build path I was using. In the running image, the UI appears to be embedded in the Caddy binary under /usr/bin/caddy rather than present as a directly editable file, so I could not do a quick in-container patch test.

That said, based on the browser behavior, this looks like a frontend validation issue: the form submit is blocked because the label field is still required at submit time.

I was not able to test this patch end-to-end yet, but this is the minimal workaround/fix I would expect to solve it:

line 545 ->

<!-- App Authentication Registration Scripts -->
<script src="{{ pathjoin .ActionEndpoint "/assets/js/sandbox_mfa_add_app.js" }}"></script>
<script>
document.querySelector('.mfa-add-app-form')?.addEventListener('submit', () => {
  const el = document.querySelector('input[name="label"]');
  if (el && !el.value.trim()) el.value = 'Auth';
});
</script>
{{ end }}

[greenpau]

I was not able to fully test a proper template patch yet because I could not locate the editable source template in the build path I was using. In the running image, the UI appears to be embedded in the Caddy binary under /usr/bin/caddy rather than present as a directly editable file, so I could not do a quick in-container patch test.

@alperensozer , you can overwrite individual pages. See https://docs.authcrunch.com/docs/authenticate/ui-features#overriding-a-specific-page-template

[vnykmshr]

@greenpau, sharing my observation on the frontend issue - getQRCode() in sandbox_mfa_add_app.js hides #token-params, but the three required inputs (label, comment, secret) stay in the form. If any is empty or pattern-invalid at submit time, browser would refuse the submit - no network request, no visible feedback. Matches @alperensozer's description.

Possible fix - validate those fields in getQRCode() before the hide step or drop required/pattern off them if they are to be hidden

[alperensozer]

I got it working on local container.

I tested the sandbox template workaround, ı was able to proceed successfully.

So from my side, this workaround does fix the issue I was hitting with the form not submitting.

The problem does appear to be related to the label field / frontend validation behavior.

Caddyfile ->

ui {
    theme basic
    template sandbox /etc/caddy/sandbox.template
}

-> local sandbox.template

<script src="{{ pathjoin .ActionEndpoint "/assets/js/sandbox_mfa_add_app.js" }}"></script>
<script>
document.querySelector('.mfa-add-app-form')?.addEventListener('submit', () => {
  const el = document.querySelector('input[name="label"]');
  if (el && !el.value.trim()) el.value = 'Auth';
});         
</script>   
{{ end }}   
{{ if or (eq .Data.view "mfa_u2f_register") (eq .Data.view "mfa_u2f_auth") }}