Describe the bug
When enabling OIDC login, Kutt always forces the user to re-authenticate at the IdP on every login attempt (and often on repeated visits), even when the user already has a valid IdP session. The authorization request includes prompt=login, which forces the IdP to require interactive login each time.
This prevents “true SSO” behavior and makes OIDC UX much worse than expected.
To Reproduce
Run Kutt with OIDC enabled (tested on the current branch that includes the OIDC login button).
Configure an OIDC provider (Authelia in my case) and set the correct redirect URI.
Open https:///login and click the OIDC login button.
Observe the authorization request sent to the IdP includes prompt=login.
Even if the user is already authenticated on the IdP, the IdP forces a new login / MFA step because of prompt=login.
Observed behavior
The authorization request looks like this (example, sanitized):
https://auth.example.com/api/oidc/authorization
?client_id=kutt
&scope=openid%20profile%20email
&response_type=code
&redirect_uri=https%3A%2F%2Fkutt.example.com%2Flogin%2Foidc
&state=...
&prompt=login
&code_challenge=...
&code_challenge_method=S256
Because prompt=login is present, the IdP always forces an interactive login, so users repeatedly see the IdP login/MFA prompt instead of seamless SSO.
Expected behavior
Kutt should not force re-authentication when an IdP session already exists.
Default should be: no prompt parameter (let the IdP reuse its session and decide).
Optionally, provide configuration to control prompt (e.g. OIDC_PROMPT), but default should not be login.
Environment
Kutt: OIDC-enabled build (not the latest stable release; tested with a recent build containing the OIDC login button)
Deployment: Docker
Reverse proxy: Caddy
IdP: Authelia OIDC provider
Redirect URI used: https:///login/oidc
Additional context
This is not an IdP-specific issue: prompt=login is an OIDC standard parameter that explicitly forces reauthentication. Removing it would allow normal SSO behavior (IdP session reuse), while still supporting PKCE (code_challenge / S256) as currently implemented.
Suggested fix
Stop appending prompt=login to the authorization request by default. If you need a way to force it for some deployments, make it configurable (env var / config option), but do not force it in the default flow.
Describe the bug
When enabling OIDC login, Kutt always forces the user to re-authenticate at the IdP on every login attempt (and often on repeated visits), even when the user already has a valid IdP session. The authorization request includes prompt=login, which forces the IdP to require interactive login each time.
This prevents “true SSO” behavior and makes OIDC UX much worse than expected.
To Reproduce
Run Kutt with OIDC enabled (tested on the current branch that includes the OIDC login button).
Configure an OIDC provider (Authelia in my case) and set the correct redirect URI.
Open https:///login and click the OIDC login button.
Observe the authorization request sent to the IdP includes prompt=login.
Even if the user is already authenticated on the IdP, the IdP forces a new login / MFA step because of prompt=login.
Observed behavior
The authorization request looks like this (example, sanitized):
Because prompt=login is present, the IdP always forces an interactive login, so users repeatedly see the IdP login/MFA prompt instead of seamless SSO.
Expected behavior
Kutt should not force re-authentication when an IdP session already exists.
Default should be: no prompt parameter (let the IdP reuse its session and decide).
Optionally, provide configuration to control prompt (e.g. OIDC_PROMPT), but default should not be login.
Environment
Kutt: OIDC-enabled build (not the latest stable release; tested with a recent build containing the OIDC login button)
Deployment: Docker
Reverse proxy: Caddy
IdP: Authelia OIDC provider
Redirect URI used: https:///login/oidc
Additional context
This is not an IdP-specific issue: prompt=login is an OIDC standard parameter that explicitly forces reauthentication. Removing it would allow normal SSO behavior (IdP session reuse), while still supporting PKCE (code_challenge / S256) as currently implemented.
Suggested fix
Stop appending prompt=login to the authorization request by default. If you need a way to force it for some deployments, make it configurable (env var / config option), but do not force it in the default flow.