TOTP Problem with first OTP-Code - second one works

[soerendohmen]

Describe the bug With TOTP MFA the accepted OTP is always the second one. Meaning that you will have to wait until the first 30 secs are over. You will have to type the first code though. The second code is accepted during the whole time range.

To Reproduce Steps to reproduce the behavior: Try to login with TOTP

Expected behavior Login goes through on the first try.

Version and Deployment (please complete the following information):

• authentik version: 2023.5.3
• Deployment: kubernetes

[DarkVirtue]

I am also having this issue.

• authentik version: 2023.5.4
• Deployment: docker

When prompted for the TOTP code, entering a correct code shows the spinner for a moment, but nothing more happens. Re-entering the same code while it's still valid returns an invalid code error. After the code rolls over, the next correct code entered is successful.

[romprod]

I'm also having this issue but only when using oauth with portainer and only because I'm forced to login twice, on the first login the TOTP code works....

• authentik version: 2023.5.4 and 2023.5.3
• Deployment: docker

I've followed the guide for portainer and have even re-created the application and provider. None of the above are problems when logging into radarr etc

[DarkVirtue]

Here are the logs from the first "failed" OTP entry:

auth-server-1        | {"auth_via": "unauthenticated", "event": "/-/health/live/", "host": "localhost:8000", "level": "info", "logger": "authentik.asgi", "method": "GET", "pid": 86683, "remote": "127.0.0.1", "request_id": "0467cc04c57746bb8248389ce9bf94e2", "runtime": 31, "scheme": "http", "status": 204, "timestamp": "2023-07-02T13:58:22.875692", "user": "", "user_agent": "goauthentik.io/proxy/healthcheck"}
auth-server-1        | {"auth_via": "unauthenticated", "event": "/api/v3/flows/executor/default-authentication-flow/?query=next%3D%252F", "host": "auth.redacted.com", "level": "info", "logger": "authentik.asgi", "method": "POST", "pid": 86683, "remote": "172.21.0.4", "request_id": "e362c098b3834b7ca0b7717513b18c19", "runtime": 182, "scheme": "https", "status": 302, "timestamp": "2023-07-02T13:58:24.980558", "user": "", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0"}
auth-server-1        | {"auth_via": "unauthenticated", "event": "/api/v3/flows/executor/default-authentication-flow/?query=next%3D%252F", "host": "auth.redacted.com", "level": "info", "logger": "authentik.asgi", "method": "GET", "pid": 86683, "remote": "172.21.0.4", "request_id": "0e50ed06955541799f367b34f9d617b1", "runtime": 164, "scheme": "https", "status": 200, "timestamp": "2023-07-02T13:58:25.250522", "user": "", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0"}
auth-server-1        | {"auth_via": "unauthenticated", "event": "/api/v3/flows/executor/default-authentication-flow/?query=next%3D%252F", "host": "auth.redacted.com", "level": "info", "logger": "authentik.asgi", "method": "POST", "pid": 86683, "remote": "172.21.0.4", "request_id": "dff8aae67d5d4c558c09654a4d9961f6", "runtime": 102, "scheme": "https", "status": 200, "timestamp": "2023-07-02T13:58:25.457008", "user": "", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0"}
auth-server-1        | {"auth_via": "unauthenticated", "event": "Not setting MFA cookie since threshold is not set.", "host": "auth.redacted.com", "level": "info", "logger": "authentik.flows.stage", "pid": 93520, "request_id": "7ce4a496835144a185c1a2e0fe9abcb5", "stage": "default-authentication-flow-mfa", "stage_view": "authentik.stages.authenticator_validate.stage.AuthenticatorValidateStageView", "timestamp": "2023-07-02T13:58:46.683296"}
auth-server-1        | {"auth_via": "unauthenticated", "event": "/api/v3/flows/executor/default-authentication-flow/?query=next%3D%252F", "host": "auth.redacted.com", "level": "info", "logger": "authentik.asgi", "method": "POST", "pid": 93520, "remote": "172.21.0.4", "request_id": "7ce4a496835144a185c1a2e0fe9abcb5", "runtime": 532, "scheme": "https", "status": 302, "timestamp": "2023-07-02T13:58:46.706428", "user": "", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/114.0"}

There's a message in there: "Not setting MFA cookie since threshold is not set." What threshold is being referred to here?

[DarkVirtue]

Issue is still present on 2023.6.0

[soerendohmen]

Issue is still present on 2023.6.1

[Typositoire]

Glad to see I'm not the only one xD I was kind of worried. When it happens I shows a failed login attempt with stage default-authentication-mfa-validation being failed at.

[romprod]

Ditto for me.

Authentik 2023.6.1 Portainer 2.18.2 Docker deployment

Doesn't happen on anything else that I have setup with Authentik

[markiemm]

This is happening to me on version 2023.8.3

[markiemm]

Ok I had found the fix and this is not Authentik's fault. This is Cloudflare's caching issue.

set to bypass cache and then purge the current cache in Cloudflare

[DarkVirtue]

Glad you were able to find a solution for your issue.

However, I'm still experiencing this problem and I'm not using CloudFlare (or any caching layer).

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eglia]

I'm having the same issue, static codes are also affected. Authentik is behind Caddy with default configurations, so no caching that I can see.

[psuet]

This issue is also present in the current version utilizing Traefik as reverse-proxy without any caching

[12nick12]

I'm having the issue as well behind NGiNX reverse proxy and made sure proxy_cache off; is on the virtual_host to make sure it's not a caching issues.

[hknobbe]

Having the same issue; for TOTP and Yubikey. Neither works first time. Tried proxy_cache off; and cloudflare no-cache. Still doesn't work the first time.

[12nick12]

Any update? I'm also getting the Not setting MFA cookie since threshold is not set error

[12nick12]

Looking thru the code it appears to be related to the code at ./authentik/stages/authenticator_validate/stage.py:360: which looks like it's related to delta = timedelta_from_string(stage.last_auth_threshold). I increased the Last validation threshold * from seconds=0 to seconds=90 in the default-authentication-flow-mfa stage in the Default Authentication Flow flow with hopes they were related and it's still not working, but now I don't see the error from above.

[12nick12]

Still happening in 2023.10.7

[MaxPelly]

I get this problem and a similar thing with passkeys where the first attempt always fails and I need to refresh and give the passkey a second time to log in (issue #8401)

[depuits]

I was having this problem to. I think the problem is that there are 2 mfa stages in the default authentication flow. This makes it so you have to put in a code for the first mfa stage and after that one you need a code for the second stage. By that stage the application will probably have marked the first code as already used forcing you to wait for a new second code.

If I remove the second mfa stage the login behaves as I would expect. I then end up with following authentication flow:

In the following screenshot I've readded the stage I've removed:

The only difference in this second mfa stage is that it let's the user continue if he has no mfa configured.

[MaxPelly]

This seems to fix #8401 as well. As far as I can tell things work exactly as expected, bad username, can login. Bad password, can't login, don't give the passkey, can't login. Also still seems to work fine for accounts with no mfa on them. Is there a subtle security issue somewhere on removing the block?

[MaxPelly]

Agh and then I went ahead and updated to 2024.2.1 and now I get an authentication failed error the first time I present the passkey with and without that stage. Would seem if you are having this issue stay on 2023

Edit: The update to 2024 undoes the change! Applying it again fixes things!

[depuits]

I'm also on 2024.2.1 and for me it is working. I'm only using totp so your issue might be something different with the passkey. I've done this change in the previous version and had to redo it after the update, that's why I've found this thread looking for a more permanent solution.

[MaxPelly]

the update reset it? Now I didn't think to check that! edit: that was the issue!!!!

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[DarkVirtue]

Removing the second MFA stage (default-authentication-mfa-validation) solved the issue for me, but the stage was returned to the flow when I updated to 2024.4.0.

[MaxPelly]

Can confirm, most annoying

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[psuet]

still anoying and not intuitive.

[authentik-automation[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.