[Bug] Unable to login with Microsoft Entra ID auth

[ydfdas1f546g1df]

Gokapi Version

v2.2.4

Operating System / Deployment

Docker (Official Image)

Storage Backend

Local Disk

Database

SQLite

Steps to Reproduce

1: Try to login

Additional Context

Bug: OAuth Login Uses prompt=consent Instead of prompt=select_account

Some users are unable to log in to the Gokapi admin interface at /admin when using Microsoft Entra ID / Azure AD as the OIDC provider.

Instead of completing the login flow, they are shown an approval/consent screen. This is a problem in tenants where users are not allowed to grant application consent themselves.

Current Behaviour

When opening the admin login, Gokapi redirects users to Microsoft with an authorize URL similar to this:

https://login.microsoftonline.com/<ORG ID>/oauth2/v2.0/authorize?client_id=<Client ID>&redirect_uri=<GOKAPI URL>%2Foauth-callback&response_type=code&scope=openid+profile+email&state=<state>&prompt=consent&sso_nonce=<>&client-request-id=<>&mscrid=<>

The important part is:

prompt=consent

This forces Microsoft to show a consent prompt. If the tenant blocks user consent, the login fails or requires administrator approval.

Expected Behaviour

The authorize request should use:

prompt=select_account

or omit the prompt parameter unless consent is explicitly required.

Using prompt=select_account allows the user to select the correct Microsoft account without forcing a new consent request.

Workaround Tested

I manually replaced:

prompt=consent

with:

prompt=select_account

After that, the login worked without issues.

Why This Matters

Many companies disable user consent in Microsoft Entra ID for security reasons. In those environments, forcing prompt=consent breaks the login flow for normal users, even if the application permissions were already granted by an administrator.

Related Issue

This appears to be related to / a duplicate of #272, but the issue does not seem to be resolved.

Relevant Logs

Before submitting

• I have removed sensitive information (API keys, passwords) from my logs.

[Forceu]

Copied from #402

---

Thanks for the issue/PR.

Unfortunately login forces the user to re-enter the password for most OIDC providers, even if a session already exists. In your case select_account would probably be a better alternative, although I have to do some testing with that, as (at least a couple of years ago), that caused some other problems as well.

I would be open to add an option to chose between consent and select_account. Can you please report back, if select_account works for you as well?

[ydfdas1f546g1df]

Yes, select_account works for us.

I tested it in our dev environment with a few users, and it resolved the repeated consent prompt issue. Users can now select their existing account/session instead of being forced through the consent flow again.

[Forceu]

Fixed in 66ff9e6, thanks for the report!