[Bug]: OIDC signs in successfully but fails to forward client to a dashboard

[JakePi3]

Describe the bug

I used SSO via Authelia on v5 which worked fine.
After upgrading to v6 the web client stays stuck on the login page. Following the auth flow I see the following screen:

Signed in successfully. Loading Pulse…

This login page is shown indefinitely and I have to manually type in a dashboard address (such as /proxmox/overview) in order to access the system.

I do see that security/status response has valid elevated capabilities but:

"ssoSessionUsername": "",
"ssoSessionDisplayName": ""

which may be the reason why I'm not being redirected to a dashboard.

Backend logs are showing successful sso_oidc_login event
Cookies correctly set AND sent on subsequent requests

TLDR: OIDC works as before but gets stuck on login page without showing a dashboard.

To reproduce

As above. Login via SSO. Remain on login page.

Expected behavior

I expected to be redirected to a dashboard with no manual action on my part, same as what happens when I use a direct admin login.

Pulse version

v6.0.5

Agent version

none

Image tag or digest

unknown

Installation type

ProxmoxVE LXC

Relevant logs or diagnostics

root@pulse:/etc/pulse# pulse --version
Pulse v6.0.5


{
    "agentUrl": "http://192.168.1.100:7655",
    "apiTokenConfigured": true,
    "apiTokenHint": "...",
    "authLastModified": "2026-07-13T16:21:57Z",
    "authUsername": "admin",
    "clientIP": "192.168.1.92",
    "configuredButPendingRestart": false,
    "credentialsEncrypted": true,
    "exportProtected": true,
    "hasAuditLogging": true,
    "hasAuthentication": true,
    "hasHTTPS": true,
    "hasProxyAuth": false,
    "hideLocalLogin": false,
    "isPrivateNetwork": true,
    "isTrustedNetwork": true,
    "presentationPolicy": {
        "demoMode": false,
        "readOnly": false,
        "hideCommercial": false,
        "hideUpgrade": true
    },
    "proxyAuthIsAdmin": false,
    "proxyAuthLogoutURL": "",
    "proxyAuthUsername": "",
    "publicAccess": false,
    "requiresAuth": true,
    "sessionCapabilities": {
        "demoMode": false,
        "assistantEnabled": false
    },
    "settingsCapabilities": {
        "apiAccessRead": true,
        "apiAccessWrite": true,
        "authenticationRead": false,
        "authenticationWrite": false,
        "singleSignOnRead": true,
        "singleSignOnWrite": true,
        "roles": false,
        "users": false,
        "auditLog": false,
        "auditWebhooksRead": false,
        "auditWebhooksWrite": false,
        "relayRead": false,
        "relayWrite": false,
        "billingAdmin": false
    },
    "ssoEnabled": true,
    "ssoLogoutURL": "",
    "ssoProviders": [
        {
            "id": "legacy-oidc",
            "name": "Single Sign-On",
            "type": "oidc",
            "displayName": "Single Sign-On",
            "loginUrl": "/api/oidc/legacy-oidc/login"
        }
    ],
    "ssoSessionDisplayName": "",
    "ssoSessionUsername": "",
    "unprotectedExportAllowed": false
}

Confirmations

• I verified the exact Pulse version and image reference from the running instance.
• I searched existing issues for duplicates.

[rcourtman]

Found it, and it is two stacked bugs on my side, not your Authelia config. Your provider issued no refresh token (offline_access not requested), and Pulse only marked a session as SSO when a refresh token came with it, which is exactly why security/status showed an empty ssoSessionUsername. The login page then refused to hand over to the dashboard because it saw no evidence of a session it recognised, even though the cookie was valid, which is why deep links worked. Both layers are fixed on main: sessions are now stamped as OIDC regardless of refresh token, and a completed SSO callback proceeds to the dashboard on cookie evidence alone. Will be in the next release; please retest on it and I'll close once confirmed.