Use OIDC as an authentication between APP and Nextcloud

[bitvilag]

I currently use keycloak as user backend using the OIDC protocol and I am moving the nextcloud instance to this as well. I was wondering if you ever tried to interact with nextcloud using tokens creating a personal account/space for the user?

[kwisatz]

Hi @bitvilag,

No, so far we haven't tried that. In our original use-case, the our APP users aren't the ones authenticating against Nextcloud, but only the app is. However, an approach where different workflows or actions use different authentication contexts does make a lot of sense, especially if you don't want to create a separate user for your app on Nextcloud or if your app-user has a more restricted role than some of the users do.

Correct me if I'm wrong, but I think the authentication flow using an OID Identity Provider or back-end such as KeyCloak would be such as this:

1. User logs in to APP (using OIDC or not)
2. User is asked to connect to Nextcloud
3. User authenticates with the OID back-end to connect to Nextcloud (using e.g. OpenID Connect Login) and we get a JWT that we can use for initial API requests
4. an application password is generated for the user and the APP (requested via the Nextcloud REST API) and securely stored within the App (or within keycloak)
5. any communication between the APP and Nextcloud in the user context now uses the application password (aka token)

I'm not sure how advanced OIDC integration is in that OIDC Login app. I suppose it can pull roles from either the user back-end (e.g. keycloak) or from LDAP and I suppose that, similar to what happens with the LDAP user back-end alone, a local copy of the user (reference) is still created on Nextcloud.

I'm also a bit uncertain about the steps 3 and 4. So if you could confirm or correct my assumptions, that'd be appreciated. I could e.g. imagine that rather than storing the application password inside the APP, it could also be stored in keycloak and retrieved as an access token together with the JWT.

As I mentioned above, I see how this could make sense, but I'm not sure how quickly we could get to implementing this, given that it technically all works out. I would also see us implementing this in two steps, first without any OIDC support, then adding that on top. The process of authenticating with Nextcloud as a user, generating an application password and then using that doesn't differ, but storage and the initial authentication against both Nextcloud and the APP may introduce further complexity.

For completeness' sake, we should also acknowledge, that

• Nextcloud can act as an OIDC IP (see also this github ticket)

[bitvilag]

Hi @kwisatz,

In my use-case, I was wondering how could my app remain stateless without any persistent storage. Obviously the DB is running somewhere on persistent storage.

Generally I am designing and implementing my app that I have front-end and back-end both attached to keycloak running as multiple instances.

Technically I can assign now roles to the user which I can be enforced on both front-end and back-end.

Now comes in the question, how should I handle the files that needs to be uploaded, but only visible to the uploaded user (or maybe a group of users)?

How should I make the user possible to interact and only interact with their own files.

User and password is not even asked as I use google/fb/etc integration though it does support local users.

My thought was to impersonate the user and connect to nextcloud using the impersonation as it would reach the users account only.

This means technically the user could also login to the nextcloud directly, though I don't see at the moment a too big issue as I would limit the storage anyhow. Maybe this is wrong, not sure.

Whats even more wild is allow the user (through api calls) to attach their own google drive to nextcloud and use my app together with their own google drive though not sure on the effort side. This would be probably something I would not implement in the near future.

Generally I would like to able the user to upload files, but not to the container the app is running in, but rather to nextcloud directly.

I then forsee something like:

• something.com is the app (which is the case now)
• api.something.com is api server (which is the case now)
• files.something.com is the "attachment" server

I am not that experienced with this model, so I might not be on right track and might have not reached you with the correct assumptions.

[bitvilag]

I moved away from this solution therefore it is not needed for now.

[kwisatz]

This is still not a bad idea, re-opening this issue.