[OIDC] Using different client IDs with OpenCloud & Authentik (Web, Desktop, iOS Client)

[dennisoderwald]

Update: Unfortunately, the simple Nginx rewrite did not cover all eventualities, so we wrote our own proxy in Go, which you can find here: https://github.com/2bros-group/opencloud-oidc-webfinger-proxy

---

We use Authentik as our IdP and have encountered the same issues reported by others - specifically, that the different client IDs cause problems.

We’ve found a temporary workaround until the core issue is resolved, and we’d like to share it with you. Of course, we’re open to any suggestions for improvement.

This solution has been tested with the official web, desktop (macOS), and iOS clients.
We haven’t yet been able to test it with Android.

The idea is simple: intercept the /.well-known/webfinger path in your reverse proxy and modify the response so that the correct issuer is returned.

Nginx Example:

location = /.well-known/webfinger {
        default_type application/json;
        add_header Content-Type "application/json; charset=utf-8" always;
        add_header Access-Control-Allow-Origin "*" always;
        add_header Cache-Control "no-store" always;
        add_header X-Content-Type-Options "nosniff" always;

        return 200 '{"subject":"https://cloud.domain.com/","links":[{"rel":"http://openid.net/specs/connect/1.0/issuer","href":"https://auth.domain.com/application/o/${issuer_suffix}/"}]}';
    }

Additionally, you can map user agents to return the appropriate issuer:

map $http_user_agent $issuer_suffix {
    "~*mirall.*OpenCloud"  "opencloud-desktop";
    "~*OpenCloudApp"       "opencloud-ios";
    "~*OpenCloud-android"   "opencloud-android";
    default                "opencloud";
}

Required environment variable:

Make sure to set the following environment variable:

PROXY_OIDC_REWRITE_WELLKNOWN=true
PROXY_OIDC_ACCESS_TOKEN_VERIFY_METHOD=none

By default, this value is set to jwt.
According to the official documentation: https://docs.opencloud.eu/de/docs/dev/server/Services/proxy/proxy-envvars

Sets how OIDC access tokens should be verified.
Possible values are none and jwt.
When using none, no special validation apart from using it for accessing the IdP's userinfo endpoint will be done.
When using jwt, it tries to parse the access token as a JWT token and verifies the signature using the keys published on the IdP's jwks_uri.

⚠️ Use this setting with caution.

Disabling token signature verification (none) lowers the level of security - tokens will not be validated cryptographically.
Only use this option if you fully understand the implications and have other means of ensuring trusted communication between your Reverse Proxy, OpenCloud, and Authentik.

This approach is certainly not perfect, but it works reliably in our tests with the clients mentioned above.

[dennisoderwald]

We have just discovered that Webfinger (https://github.com/opencloud-eu/opencloud/tree/main/services/webfinger) returns different responses depending on the query parameter, so we will be redesigning the whole thing. An update will follow. :)

[dennisoderwald]

Update: Unfortunately, the simple Nginx rewrite did not cover all eventualities, so we wrote our own proxy in Go, which you can find here: https://github.com/2bros-group/opencloud-oidc-webfinger-proxy

[micbar]

@dennisoderwald awesome

could you imagine to add some of the code to the webfinger service in openCloud?

@rhafer and @butonic suggested to use the webfinger service as a permanent solution.

[dennisoderwald]

@micbar The solution is clearly a workaround that solves the problem for now, but it's not a clean implementation that belongs in the core. That's why I created it separately, besides the fact that the code could definitely be improved in terms of quality. :-)

So no, as things stand right now, I don't think I can do that, besides the fact that I think the core team first has to decide how they want to deal with it in the future and implement the whole thing.

On the one hand, this is about the client ID, but in my opinion, the scope request of the clients, which is currently hardcoded for everything that is not web-based, should also be controllable.

[micbar]

We intend to provide all that information for the clients via the webfinger, that the clients can fetch scopes, client IDs and issuers from the webfinger.

[micbar]

The clients are already asking the webfinger endpoint. So it requires small changes in the clients to discover the server requirements.