[BUG] Session is not refreshed when using Keycloak

[woggioni]

Steps to reproduce

1. Configure opencloud to use OIDC authentication with Keycloak
2. Install Opencloud iOS app
3. Log in with Opencloud iOS app

Expected behavior

You should be able to log in and the session should remain active, close to the session expiration the refresh
token should be used to extend the session

Actual behavior

The application logs in successfully but then the session cannot be extended, when that happens the application goes in offline mode and it's not even possible to log back in again, the only way forward is to delete the account from the app and re-create it again

Client

iOS version: 18.5

OpenCloud app version: 1.0.1 build 3

Device model: iPhone 14 Pro Max

Server configuration

OpenCloud version: 2.3.0

Logs

OpenCloud server error log

Insert your OpenCloud server log here

Tell us what could be improved:

[kulmann]

Could you share the oidc client configuration for the OpenCloud iOS app that you have in keycloak, please?

[woggioni]

{
  "clientId": "OpenCloudIOS",
  "name": "OpenCloud iOS App",
  "description": "",
  "rootUrl": "",
  "adminUrl": "",
  "baseUrl": "",
  "surrogateAuthRequired": false,
  "enabled": true,
  "alwaysDisplayInConsole": false,
  "clientAuthenticatorType": "client-secret",
  "redirectUris": [
    "oc://ios.opencloud.eu"
  ],
  "webOrigins": [],
  "notBefore": 0,
  "bearerOnly": false,
  "consentRequired": false,
  "standardFlowEnabled": true,
  "implicitFlowEnabled": false,
  "directAccessGrantsEnabled": true,
  "serviceAccountsEnabled": false,
  "publicClient": true,
  "frontchannelLogout": true,
  "protocol": "openid-connect",
  "attributes": {
    "request.object.signature.alg": "any",
    "request.object.encryption.alg": "any",
    "client.introspection.response.allow.jwt.claim.enabled": "false",
    "standard.token.exchange.enabled": "false",
    "post.logout.redirect.uris": "oc://ios.opencloud.eu",
    "frontchannel.logout.session.required": "true",
    "oauth2.device.authorization.grant.enabled": "false",
    "backchannel.logout.revoke.offline.tokens": "false",
    "use.refresh.tokens": "true",
    "realm_client": "false",
    "oidc.ciba.grant.enabled": "false",
    "client.use.lightweight.access.token.enabled": "false",
    "backchannel.logout.session.required": "true",
    "request.object.required": "not required",
    "client_credentials.use_refresh_token": "false",
    "access.token.header.type.rfc9068": "false",
    "tls.client.certificate.bound.access.tokens": "false",
    "require.pushed.authorization.requests": "false",
    "display.on.consent.screen": "false",
    "request.object.encryption.enc": "any",
    "token.response.type.bearer.lower-case": "false"
  },
  "authenticationFlowBindingOverrides": {},
  "fullScopeAllowed": true,
  "nodeReRegistrationTimeout": -1,
  "defaultClientScopes": [
    "web-origins",
    "acr",
    "profile",
    "roles",
    "basic",
    "email"
  ],
  "optionalClientScopes": [
    "address",
    "phone",
    "offline_access",
    "microprofile-jwt"
  ],
  "access": {
    "view": true,
    "configure": true,
    "manage": true
  }
}

[kulmann]

@rhafer or @micbar do you see anything wrong with this config?

[woggioni]

I think I've resolved the issue after setting the environmental variable PROXY_OIDC_REWRITE_WELLKNOWN to true in the opencloud container (it was set to false before)

[rhafer]

@rhafer or @micbar do you see anything wrong with this config?

No. Looks fine on a quick glance.

[michaelstingl]

I think I've resolved the issue after setting the environmental variable PROXY_OIDC_REWRITE_WELLKNOWN to true in the opencloud container (it was set to false before)

close?

[woggioni]

no, actually the problem still persists :-(

[woggioni]

I'm still trying to solve this... I don't have many clues but I noticed that every time I log in from the iOS app a new client with a random clientId in Keycloak is created as in this picture

Is this expected? (from my experience of using Keycloak, this should not happen and I was expecting all the app sessions to use the OpenCloudIOS client)

[woggioni]

I disabled client registration with the client registration service in Keycloak adding adding a "Trusted Host Policy" with no trusted hosts as recommended on the official documentation. This prevented the opencloud iOS app from creating new clients and somehow forced it to use the OpenCloudIOS client I had specifically created for it (the logic behind this goes beyond me though... I cannot understand why the app was trying to register its own client in the first place, especially considering a client with the well-known OpenCloudIOS name already existed). The issue seems now solved...

[rhafer]

@guruz It looks as if the iOS App is preferring dynamic client registration over the default "OpenCloudIOS" client. Could you take a look?

[michaelstingl]

@rhafer The iOS app doesn't "prefer" dynamic client registration. It only attempts dynamic registration when the IdP (Keycloak) explicitly announces support for it via the registration_endpoint in .well-known/openid-configuration.

Here's the actual flow:

1. The app queries .well-known/openid-configuration
2. Only if Keycloak includes a registration_endpoint in the response, the app attempts dynamic registration
3. If dynamic registration fails (or isn't announced), the app falls back to the preconfigured "OpenCloudIOS" client

The issue is that Keycloak is announcing dynamic client registration support but then failing to handle it properly for public clients.

Reference: OpenCloudSDK/Authentication/OCAuthenticationMethodOAuth2.m:117

Solutions:

1. Configure Keycloak to not announce the registration_endpoint if it doesn't support public client registration
2. Or ensure the "OpenCloudIOS" client is properly configured in Keycloak with redirect URI oc://ios.opencloud.eu
3. Or disable dynamic registration via MDM/branding: oidc-register-client: false

(Updated: fixed link to ios-sdk submodule)

[woggioni]

There doesn't seem to be a way to remove the registration_endpoint from the .well-known/openid-configuration in Keycloak though (at least I couldn't find it anywhere in the official documentation)