"claim not set or empty" when logging in from desktop clients

[seriousm4x]

Describe the bug

I can't login from desktop clients anymore. When trying to login, the client app shows "Authentication process failed. Do you want to retry and start over?"
Ocis logs the following error:

{
  "level": "error",
  "service": "proxy",
  "claim": "lg.uuid",
  "claims": {
    "email": "<my email>",
    "email_verified": false,
    "family_name": "max",
    "name": "max",
    "preferred_username": "max",
    "sub": "<don't know if it's ok to share...>"
  },
  "time": "2023-05-29T12:47:37.358849346Z",
  "message": "claim not set or empty"
}

I'm using ocis 3.0.0-rc.4. Both Windows and Linux clients use the latest version 4.0.0.
Using the web interface works just fine.

Steps to reproduce

Steps to reproduce the behavior:

1. Update to ocis to 3.0.0-rc.4
2. Clients won't sync anymore (expired credentials i guess)
3. Try to relogin with authenticating through browser
4. Login fails

Also completely removing the account from the client and re-adding won't work either.

Expected behavior

Login succeeds

Actual behavior

Ocis throws error caused by this line:

ocis/services/proxy/pkg/middleware/account_resolver.go

Line 63 in 0972955

m.logger.Error().Str("claim", m.userOIDCClaim).Interface("claims", claims).Msg("claim not set or empty")

Setup

I'm using docker on unraid. This is my compose file:

services:
  ocis:
    container_name: ocis
    image: owncloud/ocis:latest
    user: 1000:1000
    entrypoint:
      - /bin/sh
    command: ["-c", "ocis init || true; ocis server"]
    environment:
      OCIS_URL: "https://<my domain>"
      OCIS_INSECURE: "true"
      PROXY_TLS: "false"
      PROXY_HTTP_ADDR: "0.0.0.0:9200"
    volumes:
      - /mnt/user/appdata/ocis/config:/etc/ocis
      - /mnt/user/appdata/ocis/data:/var/lib/ocis
    restart: unless-stopped
    networks:
      - proxy-manager
networks:
  proxy-manager:
    external: true

Additional context

I'm also not able to login from my iPhone anymore. When I try to do so, server logs are getting spamed non stop with error logs:

{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending","time":"2023-05-29T13:01:32.175652869Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/shares","time":"2023-05-29T13:01:32.175687551Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/shares","time":"2023-05-29T13:01:32.175634644Z","message":"failed to authenticate the request"}
{"level":"error","service":"idp","error":"ldap identifier backend get user error: user does not exist or too many entries returned","time":"2023-05-29T13:01:32.227522292Z","message":"IdentifierIdentityManager: fetch failed to get user from userID"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/cloud/capabilities","time":"2023-05-29T13:01:32.243008626Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/remote_shares","time":"2023-05-29T13:01:32.253886578Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/shares","time":"2023-05-29T13:01:32.253886526Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending","time":"2023-05-29T13:01:32.253889504Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/shares","time":"2023-05-29T13:01:32.253896255Z","message":"failed to authenticate the request"}
{"level":"error","service":"idp","error":"ldap identifier backend get user error: user does not exist or too many entries returned","time":"2023-05-29T13:01:32.29640706Z","message":"IdentifierIdentityManager: fetch failed to get user from userID"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/cloud/capabilities","time":"2023-05-29T13:01:32.410356439Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/shares","time":"2023-05-29T13:01:32.41486368Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/remote_shares/pending","time":"2023-05-29T13:01:32.414897732Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/shares","time":"2023-05-29T13:01:32.414919677Z","message":"failed to authenticate the request"}
{"level":"error","service":"proxy","error":"failed to verify access token: token contains an invalid number of segments","authenticator":"oidc","path":"/ocs/v2.php/apps/files_sharing/api/v1/remote_shares","time":"2023-05-29T13:01:32.414994061Z","message":"failed to authenticate the request"}

[C8opmBM]

I have been having the same issue since last update.
Solution I figured it out myself (after wiping and trying lots of combinations):

In my case I use Authelia.
Adding the following in the docker compose let me login again:

      PROXY_AUTOPROVISION_ACCOUNTS: "true"
      PROXY_USER_OIDC_CLAIM: "email"

Hope this will work for you as well.

BTW, I'm using this guide:
https://helgeklein.com/blog/owncloud-infinite-scale-with-openid-connect-authentication-for-home-networks/

[seriousm4x]

@C8opmBM Thank you! That seems to have fixed it. Login works as expected again.

I'm leaving this issue open, as I'd like this to be documented and/or fixed in the stable release as other users will run into the same issue.

[C8opmBM]

I think this should be checked, since the console now is spammed with error messages, even though the login works.
Can you also check?

I'm getting

2023-05-29T17:46:14Z ERR failed to add user error="LDAP Result Code 68 \"Entry Already Exists\": " line=github.com/owncloud/ocis/v2/services/graph/pkg/identity/ldap.go:197 request-id=owncloud/Eb9hHktEdc-000039 service=graph
05/29/2023 8:46:14 PM
2023-05-29T17:46:14Z ERR could not create user: backend error error=nameAlreadyExists line=github.com/owncloud/ocis/v2/services/graph/pkg/service/v0/users.go:320 request-id=owncloud/Eb9hHktEdc-000039 service=graph
05/29/2023 8:46:14 PM
2023-05-29T17:46:14Z WRN Error Response OData Error="a user with that name already exists" line=github.com/owncloud/ocis/v2/services/proxy/pkg/user/backend/cs3.go:232 service=proxy

[C8opmBM]

It seems I am assigned as a normal user. Will look more into this, if someone could help, that'd be awesome :)

[seriousm4x]

I think this should be checked, since the console now is spammed with error messages, even though the login works.
Can you also check?

I'm seeing the same logs.

It seems I am assigned as a normal user

I'm the only user - admin.

[C8opmBM]

Yes, your name is admin, but you are regular user. Check if you have access to anything but your profile.
I found a related issue #6331
I've tried to add the snippet mentioned there in the proxy section, but it doesn't work for me.
I'm not using Authentik, so maybe that's the problem.

Keep this open, maybe we'll get a fix or a solution for Authelia. Meanwhile, I will revert to 3.0.0-rc.3 which does not exhibit this behaviour.

[rhafer]

@seriousm4x @C8opmBM between rc3 and rc4 we needed to change defaults for PROXY_USER_OIDC_CLAIM and PROXY_USER_CS3_CLAIM. Unfortunately the implications of that weren't properly documented in the release notes of rc4. We've fixed that last week (https://github.com/owncloud/ocis/blob/master/changelog/3.0.0_2023-05-22/fix-idp-sub-recreation.md),

To get back the rc3 behavior setting PROXY_USER_OIDC_CLAIM=preferred_username and PROXY_USER_CS3_CLAIM=username should help.

[C8opmBM]

@rhafer thank you, that fixed everything.
Have a great day!

[C8opmBM]

@rhafer forgot to ask, since you recommended a workaround to have the earlier behaviour, should this affect the future releases? In case we want the current behaviour (owncloudUUID for computing the sub claim) is there any documentation on how to achieve that?
Or it should be explained in a future documentation update?
Thank you for your input and hard work.

[rhafer]

forgot to ask, since you recommended a workaround to have the earlier behaviour, should this affect the future releases?

IIUC you're not using the builtin IDP, but some external one (authelia?) right? In that case, as long as you explicitly set PROXY_USER_OIDC_CLAIM and PROXY_USER_CS3_CLAIM you be fine.

In case we want the current behaviour (owncloudUUID for computing the sub claim) is there any documentation on how to achieve that?

That change ("use owncloudUUID for computing the sub claim") was specific to our builtin idp (lico). We can't influence how external IDPs compute the sub claim. The problematic change for setups using external IDPs were the changed defaults for PROXY_USER_OIDC_CLAIM and PROXY_USER_CS3_CLAIM.

But we need to revert that part of the change now anyway, since it is triggering an issue in lico, which causes the desktop client to no longer work. (#6415)

Or it should be explained in a future documentation update?

We definitely need to add more documentation on how to properly integrate with external IDPs.