Expired token generating error log entry every 5 minutes

[lynix]

Describe the bug

A log entry complaining about an expired access token is generated exactly every 5 minutes. Both the web interface as well as the desktop client work normally, no actual re-login is triggered.

2025-05-22T10:16:09Z ERR failed to authenticate the request error="failed to verify access token: token has invalid claims: token is expired" authenticator=oidc client.address=2a01:xxx::1 network.peer.address= network.peer.port= path=/graph/v1.0/me/drives service=proxy user_agent="Mozilla/5.0 (Linux) mirall/1.0.0 (OpenCloud, arch-6.14.2-arch1-1 ClientArchitecture: x86_64 OsArchitecture: x86_64)"
2025-05-22T10:21:10Z ERR failed to authenticate the request error="failed to verify access token: token has invalid claims: token is expired" authenticator=oidc client.address=2a01:xxx::1 network.peer.address= network.peer.port= path=/graph/v1.0/me/drives service=proxy user_agent="Mozilla/5.0 (Linux) mirall/1.0.0 (OpenCloud, arch-6.14.2-arch1-1 ClientArchitecture: x86_64 OsArchitecture: x86_64)"
2025-05-22T10:26:11Z ERR failed to authenticate the request error="failed to verify access token: token has invalid claims: token is expired" authenticator=oidc client.address=2a01:xxx::1 network.peer.address= network.peer.port= path=/graph/v1.0/me/drives service=proxy user_agent="Mozilla/5.0 (Linux) mirall/1.0.0 (OpenCloud, arch-6.14.2-arch1-1 ClientArchitecture: x86_64 OsArchitecture: x86_64)"

Steps to reproduce

1. Launch via docker compose as described in documentation
2. Connect desktop client
3. Leave idle

Expected behavior

No error log entry is generated.

Actual behavior

An error log entry is generated every 5 minutes.

Setup

# docker-compose.yml

services:
  app:
    container_name: opencloud
    image: opencloudeu/opencloud-rolling:latest
    entrypoint:
      - /bin/sh
    command: ["-c", "opencloud init || true; opencloud server"]
    read_only: true
    restart: unless-stopped
    user: 969:969  # opencloud
    security_opt:
      - no-new-privileges:true
    volumes:
      - ./config:/etc/opencloud:ro
      - ./data:/var/lib/opencloud
    tmpfs:
      - /tmp:uid=969,gid=969,size=64M
    ports:
      - 9200:9200
    environment:
      FRONTEND_ARCHIVER_MAX_SIZE: "10000000000"
      GATEWAY_GRPC_ADDR: 0.0.0.0:9142
      IDM_ADMIN_PASSWORD: "xxx"
      IDM_CREATE_DEMO_USERS: "false"
      IDP_DEFAULT_SIGNIN_PAGE_TEXT: ""
      MICRO_REGISTRY_ADDRESS: 127.0.0.1:9233
      NATS_NATS_HOST: 0.0.0.0
      NATS_NATS_PORT: 9233
      NOTIFICATIONS_SMTP_AUTHENTICATION: ""
      NOTIFICATIONS_SMTP_ENCRYPTION: none
      NOTIFICATIONS_SMTP_HOST: host.docker.internal
      NOTIFICATIONS_SMTP_INSECURE: "true"
      NOTIFICATIONS_SMTP_PASSWORD: ""
      NOTIFICATIONS_SMTP_PORT: 25
      NOTIFICATIONS_SMTP_SENDER: "OpenCloud <noreply@xxx.org>"
      NOTIFICATIONS_SMTP_USERNAME: ""
      OC_ADD_RUN_SERVICES: notifications
      OC_INSECURE: "false"
      OC_LOG_COLOR: "true"
      OC_LOG_LEVEL: warning
      OC_LOG_PRETTY: "true"
      OC_URL: https://xxx.org
      PROXY_ENABLE_BASIC_AUTH: "true"
      PROXY_HTTP_ADDR: 0.0.0.0:9200
      PROXY_TLS: "false"

Additional context

I'm running Treafik (natively on the host) as front-end for TLS termination.

[rhafer]

A log entry complaining about an expired access token is generated exactly every 5 minutes. Both the web interface as well as the desktop client work normally, no actual re-login is triggered.

I think we should tone done the log level of that message to debug. Error is clearly wrong as clients trying to use expired tokens happens very regularly and does not indicate a bug.

[nicokaiser]

clients trying to use expired tokens happens very regularly and does not indicate a bug

I'm not entirely sure about this: when using OAuth (OIDC) tokens, clients receive the expires_in time along with the token. So clients do know exactly when the token is about to expire and should never require to use an expired token.

Of course there are exceptions, e.g. when users are being logged out and their tokens are invalidated, or maybe when in-flight requests are being retried after app sleep or something like that, but I cannot think of a usecase where expired tokens need to be used regularly.

And yet, my server logs are full of "token is expired" messages from the iOS app, the macOS native app, and the web frontend, so I suspect there is a major bug somewhere (I would not rule out that it is in my configuration, but that is actually pretty much the default config).

[HeartBurzum]

I am also seeing "token is expired" from OpenCloud-android and DAVx5 quite often. The latter being annoying because of the notification of auth failure on the phone.

[micbar]

I'm not entirely sure about this: when using OAuth (OIDC) tokens, clients receive the expires_in time along with the token. So clients do know exactly when the token is about to expire and should never require to use an expired token.

Many IdPs do not use jwt tokens, in that cases, we cannot read the expiration of the token.

Of course there are exceptions, e.g. when users are being logged out and their tokens are invalidated, or maybe when in-flight requests are being retried after app sleep or something like that, but I cannot think of a usecase where expired tokens need to be used regularly.

See above. Token Timings are very hard. Some browsers are "shutting down" the inactive browser tabs, Mobile apps are not actively running when the window is not open,... and so on. So we always need to have the robust fallback for every client "Try the auth flow again when you encounter a 401".

[nicokaiser]

Many IdPs do not use jwt tokens, in that cases, we cannot read the expiration of the token.

OAuth (and thus, OIDC) usually sends the token expiration time as expires_in along with the token. So the relying party knows when the token expires, for JWTs as well as opaque tokens without inspecting them. The only special case is when tokens are revoked (e.g. user logged out, etc.) – which is a legitimate case for "token has expired" errors.

(Update: I noticed the expires_in property is only "recommended" in the OAuth spec, so there might be IdP where the the client cannot know when the token expires. When it does know however, it really should consider the expiration date)