[Auth Flow] Restricted app tokens while logging in

[MariusBluem]

Allow applications to only request an restricted app token (without file-access) for applications like Talk or Groupware-integrations which do not need file-access.

We may want to consider to give the user the permission to edit this permissions already while logging in, but I think this makes less sense, because using Nextcloud Files-app without Files-access e.g. does not work at all (for good reasons 😅).

With this introduced, we should emphasize in the login flow, that all apps, which login without restrictions can view/edit/remove all your files in a way without making the user fear to much.

Facebook (example):

As discussed with @rullzer

[rullzer]

Yes I like it.

Should at least provide the users info what will be shared. (and this should be extended if we add more permissions) etc.

Also I like the cancel button. this will need to be properly handled by the clients of course. But we should give the user a chance to opt out if they don't want it.

Of course this would require some way to indicate what permissions a request needs.

[MorrisJobke]

@rullzer I guess this is nothing for 14 anymore, right?

[rullzer]

Correct. I would love to have this in. but it needs proper planning yes.

[mario]

While I'd certainly appreciate scopes, please note that Talk apps do need file management permission due to uploading/downloading/renaming/whatever we might need.

[Grunthos]

Nice, I would definitely like this, otherwise clients are very insecure.

For apps that need file access, I note that Android apps get access to a 'hidden' part of Drive. The hidden nature is very "walled-garden" of them, but in some ways understandable. For NC, I'd suggest:

• a ".apps" root directory (or something like that, perhaps even an alternate 'root', like files-deleted, and 'files-external')
• require apps to have a unique ID. Either a uuid, or a URI/domain-like construct
• the unique ID should be global (globally unique, and the same for different installations)
• under the root, place per-app files, using a directory based on the unique ID
• make the app directories visible to the users as normal files (perhaps inside the app maintenance).

[newhinton]

@MariusBluem Why should this not apply to files aswell?

While it usually does not make sense to not grant access to no files at all, it often can make sense to limit access to files.

As an example: I have a "public" computer/device (Eg. work/university) where i want to access work/university files, but not allow access to private files.

There are two ways to manage that:

1. Custom "root" for the client
2. List of allowed folders (which by necessity include subdirs)

the second one is more complex, but would allow nearly infinite customizability.

Also i would suggest renaming the ticket to something like 'scoped app token access', which fits better.

Generally i think nextcloud should decide which scopes to grant based on the useragent. (This wont stop a malicious actor, but if a token is already created and the actor can select the scope, all is lost anyway) The configuration could be made "after the fact" in the security page

Edit: Thinking about the nextcloud sso-library: We probably also need a way to show that a token has not been granted the access to an app if we allow that kind of fine grained control.

[newhinton]

@rullzer

So, i have been experimenting on this. I have a working prototype that works as a middleware.

Currently i only check whether or not the current sessions token has access to the requested app, and throws an error otherwise. There is no ui for this at the moment, just a middleware prototype.

I plan on fully fleshing out this version in the upcoming contributors week.

My implementation can:

• Limit app access based on a token

It cannot:

• Restrict more specific routes/capabilities
• Allow apps to register above restrictions

if a token is denied, it sends a 403, with a specific header. Apps then have to handle those properly.

I would like to have some feedback on this, so that i am not overdoing things. A first implementation on app-level-blocking might be good enough, but especially for some core apps i'd like better abilities from the start. (Files/Calendars)

[newhinton]

Also, depending on the level of paranoia we want to apply to newly created token, we might have to expand on the AuthToken Class so that we can directly assign proper permissions.

(I think the usual clients should get full access (browsers/android/ios), some others limited access (desktopclients/talk) and manually created token should get no permissions per default)