"This field is required" after authenticating with correct username, password, and second factor

[swishkin]

Describe the bug
With no observed pattern thus far, Authentik will accept my correct username, password, and security key authentication, then throw me back to the username screen, showing the text "This Field is Required" under the username field.

To Reproduce
Steps to reproduce the behavior:

1. Enter the URL of any of your Authentic-protected services
2. Enter username in the username field
3. Enter password in the password field
4. Authenticate via Yubikey (WebAuthn, not Yubico auth)
5. Result: return to Username screen with error "This field is required" under the box.

Expected behavior
After successfully entering a valid username, password, and completing the WebAuthn authentication with my Yubikey, I should be logged into Authentik successfully, then redirected to my hosted service.

Screenshots

Logs

Portainer log for the Authentik container

Version and Deployment (please complete the following information):

• authentik version: 2023.5.3 (maybe an upgrade is what's needed?)
• Deployment: Portainer stack

Additional context

I think the login attempts work about one out of every five tries, on average.

I think it works more frequently if my username and password aren't auto-filled via Bitwarden (entered manually instead), but even that succeeds less than 50% of the time.

On top of failing to log in most of the time, after a successful login to Portainer, visiting Authentik itself asks for username, password, and second factor once again, and sign-in attempts have about the same success rate there.

Sometimes the login fails immediately after the password rather than after completing two-factor authentication.

Another factor which may be playing into this is that I updated the session timeout for Authentik to be something like 12 hours recently. I haven't tried reverting that change yet.

[BeryJu]

There was a bug with bitwarden (#7455), however from our testing that only affected android. The bug has been fixed with 2023.10.3, and also only happens when flow compatibility mode is enabled.

[swishkin]

After updating from 2023.5.3 to 2023.10.3, back to 2023.8.3 after reading the info in the logs, then to 2023.10.3.

It seems like the session duration is effectively zero minutes, the "This field is required" error still occurred at least once since the upgrade, and if I do successfully log into Authentik, simply reloading the page sends me straight back to the login screen.

Also, a subsequent login got me into Authentik, but then, without having to reload first, sent me straight back to the login screen again.

I wouldn't be surprised if there were some problem with my configuration, or a problem resulting from installing 2023.10.3 before 2023.8.3 as directed.

I've got a backup of my pgsql database from before the upgrade; would it be worth fully destroying the stack and restoring to 2023.10.3 from the backup?

I'm not really sure what would help diagnose or resolve this problem at this point.

[SeAIMe]

I have exact the same issue, but with a fresh install of Authentik 2023.10.3. As I don't have any experience with this software yet, I was thinking of a misconfig during install, but I can't find any...

As OP already explained, I'm getting thrown back to the login prompt almost immediately after authentication.

[swishkin]

I just confirmed the same problem occurs on 2023.10.3 using TOTP instead of WebAuthn.

[swishkin]

I'm not sure what fixed this, but I haven't run into this error for a couple days now, when it used to be ~90% of the time.

One thing that may have caused this problem is that I was using 15 year origin certs from Cloudflare for some of my services. There had been issues with being redirected to CSS files and image files as well, and those issues, too, have disappeared.

I feel like there may have been another change I made around the same time that could possibly have been involved, but I can't remember it right now.

While I'm not closing the issue immediately, I'm pretty sure using an origin cert in Nginx Proxy Manager for Authentik and several other services was the problem.

[swishkin]

Unfortunately I was incorrect; I encountered the same issue again despite correcting the certificates. Login succeeded the next time, but I did run into the problem once again.

[swishkin]

Another possible solution: I'm using Brave browser with Brave Sheilds up, and it was blocking something. I discovered this after I looked in the browser console, which showed that the client was blocking some things.

I noticed Brave shields were active, and that one item was being blocked, so I disabled them and was able to log in successfully after three failed attempts.

Again, not sure this is the actual resolution, but it seems like a good possibility, and @SeAIMe, if you're still having this issue with any consistency, you could test disabling Adblock/Brave Sheilds/whatever on the Authentik domain, and it might work better.

Let me know if that works for you, and this might be the resolution.

[SeAIMe]

Thank you @swishkin ! But I tried different browsers and that didn't change anything. Currently I'm not using Authentik any more as I couldn't get it up and running. Maybe I give it another try sometime soon.

[BeryJu]

One thing that could cause this is an incorrect reverse-proxy configuration, when you're either accessing authentik over HTTPS but authentik doesn't know it's HTTPS or vice versa. I'd tell you to use the /api/v3/admin/system/ endpoint which helps to debug this, but it requires a login. You should be able to see from the logs, looking at the scheme field, which is either http or https

[swishkin]

@BeryJu, what parts of my reverse proxy/Authentik configuration would I have to look at to help diagnose this?

[FibreTTP]

Since you use Portainer, maybe this is your issue? #4539 (comment)

Or this? #4539 (comment)

[SeAIMe]

Thank you so much @FibreTTP !

I actually fell into both traps. But now the problem is solved for me.

[authentik-automation]

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.