OIDC users don't stay logged in

[MrMeeb]

Description

I have configured Gitea to auth with Authentik via OIDC. Prior to that I was using local users, so the session would persist over a longer period, especially when 'Remember me' was ticked. I've noticed that when authenticating with OIDC, I don't remain logged in after closing the browser. This means users have to go through two extra clicks every time they visit in a new browser session.

Gitea Version

1.21.1

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

No response

Git Version

No response

Operating System

No response

How are you running Gitea?

Ubuntu/Docker

Database

MySQL/MariaDB

[p7kdev]

I have exactly the same issue (Gitea v1.22.3). I also have a Gitea + Authentik PoC. But the big problem for me is that the login does not persist. Local users can log in without any problems and remain logged in for the time configured in the app.ini. This works perfectly. The corresponding remember cookie is also set. If a user logs in via OIDC, however, no cookie is set, only the session cookie. Accordingly, these users have to log in again and again

Other apps that are connected to my OIDC provider do not have this issue. The users remain logged in there. Therefore, this should definitely have something to do with the implementation in Gitea (simply no cookie is set).

But now I'm not sure whether this might even be intentional, because it's basically also a security problem. I am noticing this in the other apps. Once you are logged in there, you stay logged in, even if you log out of the provider (Authentik).
Therefore, you should remain logged in even if the user has been blocked or deleted by an admin in Authentik. Of course, this makes the whole SSO issue a bit of a one-way street if you don't have a single logout. It might therefore be better to use LDAP integration in Gitea. Authentik also offers this. Maybe this problem does not exist there.

I'm also not sure whether this is due to the implementation or a general problem with OIDC itself.

[MrMeeb]

For what it's worth, I've somewhat eased the issue by editing the sign-in button to go straight to the OIDC flow. So it skips Gitea's login page.

[eleith]

the following thread seems relevant: https://forum.gitea.com/t/gitea-keycloak-login-session-time/9869

and i can confirm, when using local login, i have a gitea_incredible cookie set to the LOGIN_REMEMBER_DAYS offset.

but with OIDC login, no such cookie exists, and those that do are essentially 24 hours, thus i get logged out daily.

[johansmitsnl]

@MrMeeb may I ask how did you manage this?

The instance I use is private only so it would help a lot with an automatic redirect.

[ItsJustRuby]

@MrMeeb may I ask how did you manage this?

The instance I use is private only so it would help a lot with an automatic redirect.

@johansmitsnl
Not MrMeeb, but here is my setup using Caddy as reverse proxy:

@gitea host gitea.example.org
handle @gitea {
	# Convenience redirect to skip Gitea's own login screen and go
	# directly to SSO instead.
	rewrite /user/login /user/oauth2/Authelia

	reverse_proxy <gitea hostname>:<gitea port>
}

Note that Authelia here is the name of the authentication source as configurable in your Gitea instance at https://gitea.example.org/-/admin/auths

[ItsJustRuby]

With regards to the main topic: I am running Gitea 1.23.8 and encountering the same issue, being logged out from Gitea regularly while still being logged in to Authelia as SSO provider configured by OIDC.

auth.go respects the "Remember me" setting and sets an according cookie but AFAICT this never happens (and can't? shouldn't?) during the OIDC flow.

This cookie is checked in web.go when landing on the Gitea home page and an automatic redirect to /user/login happens if it is set (which accordingly performs auto login).

AFAICT this second check is missing functionality to get the current "logged in" status from the SSO provider, if configured - but I am not knowledgeable enough about authentication here to know if the correct solution wouldn't be setting the same cookies during SSO login as during normal login.

I hope this analysis will help resolve this issue 🙂

[skyone-wzw]

I’d like to add that I’m also experiencing this issue on the latest Gitea version.

In my case, I’ve configured both Passkey (via YubiKey) and OIDC as authentication methods. Login works correctly, but the session never persists after closing the browser — even when "Remember This Device" is expected to function.

However, when using Password + TOTP login, the "Remember Me" option works and keeps the session alive as intended.

This makes Passkey and OIDC inconvenient for regular use, as users must re-authenticate every time they reopen the browser.

It would be very helpful if session persistence could be supported for these external authentication methods as well. Thanks!

[thesyntaxslinger]

I’d like to add that I’m also experiencing this issue on the latest Gitea version.

In my case, I’ve configured both Passkey (via YubiKey) and OIDC as authentication methods. Login works correctly, but the session never persists after closing the browser — even when "Remember This Device" is expected to function.

However, when using Password + TOTP login, the "Remember Me" option works and keeps the session alive as intended.

This makes Passkey and OIDC inconvenient for regular use, as users must re-authenticate every time they reopen the browser.

It would be very helpful if session persistence could be supported for these external authentication methods as well. Thanks!

I am experiencing the exact same as this. When logging in with OIDC, cookies are made to clear after the session ends. When logging in without OIDC, they are back to the default 7 days.

[thesyntaxslinger]

Since this has been annoying me for so long. I have just made a bit of a bandaid fix with a user script to auto log into the authelia instance. I have my authelia setup to auto log in without a consent so this is a nice fix for my environment.

// ==UserScript==
// @name        Auto sign into Authelia
// @namespace   Violentmonkey Scripts
// @match       https://gitea.yourdomain.tld/user/login*
// @match       https://gitea.yourdomain.tld/
// ==/UserScript==

(function autoSignIn() {
    // check to see if we are on the authelia default homepage
    const rootHeader = document.querySelector('h2.tw-text-balance');
    if (rootHeader) {
        // click the sign in link
        const signInLink = Array.from(document.querySelectorAll('a.item')).find(a =>
            a.textContent.includes('Sign In')
        );
        if (signInLink) {
            signInLink.click();
            return; // this will exit the script since the script will fire again on the next page
        }
    }

    // check for the SSO link
    const autheliaLink = Array.from(document.querySelectorAll('a.oauth-login-link')).find(a =>
        a.textContent.includes('Sign in with')
    );
    // click the link then exit
    if (autheliaLink) {
        autheliaLink.click();
        return;
    };
})();

Can we get a bump on this? Quite an annoying issue and sort of defeats the whole purpose of SSO.

[silverwind]

May be specific to some OIDC provider implementations. I'm running Gitea with Keycloak OIDC provider with LOGIN_REMEMBER_DAYS = 365 and get logged out only like once per month when Keycloak expires the session, so it's working fine with Keycloak at least.

If someone could provide a reproduction repo, that would surely help narrow this down.

[gjabell]

I looked into this issue a while back and I think I had it narrowed down to incorrect use of the Expires cookie parameter. If Expires is omitted and Max-Age is not set, then the cookie will become a session cookie which is "removed when the session ends" (the exact meaning of this is a bit underdefined but theoretically it means when the browser is closed).

[silverwind]

That sound plausible. Normally without SSO, the user can choose whether they want a session cookie or not by checking "Remember me", which in turn should control the Expires attribute. With SSO, there is no such checkbox, so the only option is to always set Expires to mark the cookie as a non-session one, we should verify it does that.

Maybe someone affected could confirm whether their gitea cookie has an Expires set or not in their browser devtools.

[gjabell]

Mine certainly seems to use the session cookies:

The callback request where the cookie is set also lacks both Expires and Max-Age which explains why it becomes a session cookie: