[Bug] Proxy logs ERR failed to build subject.session error="invalid key format" on every request when using external IDP with opaque access tokens

[mariuniverse]

NOTE

**

This is written with AI help. The analysis is done with AI help because I'm not a programmer, and I have seen this error pop up after the update.

**

Describe the bug

When using Authelia as an external OIDC provider with PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none, the proxy logs an ERR level message on every single authenticated request:

ERR failed to build subject.session error="invalid key format" line=github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/oidc_auth.go:128 service=proxy
Despite this error, authentication succeeds immediately via the auth-machine fallback path, and all requests return 200. The error is non-fatal but creates significant log noise and gives the false impression that something is broken.

Steps to reproduce

Configure OpenCloud to use Authelia as an external OIDC provider with PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none and OC_EXCLUDE_RUN_SERVICES=idp
Log in via Authelia (authentication succeeds, OpenCloud is fully functional)
Observe the proxy logs — every single authenticated request produces an ERR at oidc_auth.go:128

Expected behavior

When PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD is set to none, the proxy should either skip the JWT session building attempt entirely or log the expected failure at DEBUG/TRACE level instead of ERR. No error should be logged for expected behavior with opaque tokens.

Actual behavior

The proxy attempts to parse the opaque access token (authelia_at_...) as a JWT at oidc_auth.go:128 on every authenticated request, fails with "invalid key format", then correctly falls back to the userinfo endpoint and authenticates the user via auth-machine. All requests succeed with status=200, but every request generates an ERR log entry:

2026-03-10T21:38:36Z ERR failed to build subject.session error="invalid key format" line=github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/oidc_auth.go:128 service=proxy
2026-03-10T21:38:36Z INF user idp:"https://auth.example.com"  opaque_id:"41f76c04-..."  type:USER_TYPE_PRIMARY authenticated ... service=auth-machine ...
2026-03-10T21:38:36Z INF access-log ... method=GET path=/graph/v1.0/me ... status=200 ...

Setup

OpenCloud latest rolling release (reva v2.42.5) with Authelia v4.39.15 as external OIDC provider, behind Traefik reverse proxy, deployed via Docker Compose.

ENV

OC_OIDC_ISSUER=https://auth.example.com
OC_EXCLUDE_RUN_SERVICES=idp
WEB_OIDC_CLIENT_ID=web
WEB_OIDC_SCOPE=openid profile email groups offline_access
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none
PROXY_OIDC_REWRITE_WELLKNOWN=true
PROXY_OIDC_SKIP_VERIFICATION=false
PROXY_AUTOPROVISION_ACCOUNTS=true
PROXY_ROLE_ASSIGNMENT_DRIVER=default
PROXY_USER_OIDC_CLAIM=preferred_username
PROXY_USER_CS3_CLAIM=username
PROXY_ROLE_ASSIGNMENT_OIDC_CLAIM=groups
PROXY_HTTP_ADDR=0.0.0.0:9200
GRAPH_ASSIGN_DEFAULT_USER_ROLE=true
GRAPH_USERNAME_MATCH=none

Authelia OIDC client configuration:

clients:
  - client_id: 'web'
    client_name: 'OpenCloud'
    public: true
    authorization_policy: 'two_factor'
    consent_mode: 'auto'
    pre_configured_consent_duration: '1w'
    scopes:
      - 'openid'
      - 'profile'
      - 'email'
      - 'groups'
      - 'offline_access'
    redirect_uris:
      - 'https://cloud.example.com/'
      - 'https://cloud.example.com/oidc-callback.html'
      - 'https://cloud.example.com/oidc-silent-redirect.html'
    grant_types:
      - 'authorization_code'
      - 'refresh_token'
    response_types:
      - 'code'
    response_modes:
      - 'form_post'
      - 'query'
      - 'fragment'
    userinfo_signed_response_alg: 'none'

Suggested fix:

In oidc_auth.go around line 128, check the PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD setting before attempting JWT parsing. If set to none, skip the JWT session building path and proceed directly to the userinfo-based flow. Alternatively, catch the error and log at DEBUG level since it is a known and expected condition.

Additional context

Add any other context about the problem here.

[digit4lsh4d0w]

@mariuniverse

Hello! I also encountered this error, but when I tried to roll back to a previous version, it didn't work, but there was another error related to an incorrect certificate. It seemed like our problems were occurring at the same time, so I'll write about how I fixed my error, in case it helps you.

The issue was that when you first start a Docker container, it generates certificates for LDAP and Proxy. I don't know what entities exist in OpenCloud, so I can't explain what each one does. The point is that these certificates are valid for a certain period and are typically issued for 1 year. They are self-signed, so you can re-issue them.

You can find the key and certificate pairs in the paths /var/lib/opencloud/idm and /var/lib/opencloud/proxy. You need to re-issue them. I did this using the step-cli utility like this:

step-cli certificate create "OpenCloud LDAP" ldap.crt ldap.key --profile self-signed --subtle --not-after=43800h --no-password --insecure --san "localhost" --san "127.0.0.1" --san "::1"

and like this:

step-cli certificate create "OpenCloud Proxy" server.crt server.key --profile self-signed --subtle --not-after=43800h --no-password --insecure --san "localhost" --san "127.0.0.1" --san "::1"

I'm not sure if you need to re-issue both certificates, but I did it anyway. After that, everything worked for me on the latest version of OpenCloud Rolling. These commands will allow you to generate new certificates for up to 5 years. To change this value, you should modify the --not-after flag.

Translated using "Yandex Translate".