Inability to execute JavaScript leaves authentication flow unusable

[Electromaster232]

Describe the bug While attempting to authenticate to any flow with the Microsoft AAD Broker Plugin (Microsoft.AAD.BrokerPlugin.exe, most commonly found in Microsoft Teams from the Windows Store), Authentik is stuck in a forever-loading state (likely the same issue that was found in #2396, which was closed by the issue author). The result is that users are completely unable to log into Teams when logins are run through Authentik.

To Reproduce Steps to reproduce the behavior:

1. Open Microsoft Teams and try to log in with an account that has an SSO IDP involving Authentik
2. After the initial Microsoft login flow, Authentik will be in a forever-loading state, as JavaScript cannot be executed within the Broker Plugin. (Tested via a man-in-the-middle attack, replacing the entire page with several pages with simple JavaScript snippets, none of which worked).

Expected behavior Authentik should have a way for log-ins to work without the ability to execute JavaScript. Please note that Flow Compatibility Mode did not help in this case.

Screenshots

Logs This seems to be a client-side bug, if logs are needed, please let me know.

Version and Deployment (please complete the following information):

• authentik version: 2022.6.3
• Deployment: docker-compose

[BeryJu]

Indeed the login flow currently does require JS, what confuses me though is that the Microsoft AAD Broker Plugin doesn't allow JS, since the Microsoft login site also requires JS.

A JS-less login flow would certainly be possible, at least a simple version that either

• only allows username/password auth, or
• uses an oauth device flow (which authentik can't do yet)

[davidus05]

Was looking for this, especially for https://github.com/goauthentik/authentik/issues/2396 Logging in from older devices/browsers is currently impossible.

[BeryJu]

The only option for this would be to add a fallback interface for flows that doesn't require javascript, however that is not currently planned. We'll reconsider this if there is enough demand for such a fallback interface