Repository navigation
[Auth Flow] Restricted app tokens while logging in #9117
Description
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
Activity
rullzer commentedon Apr 7, 2018
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 commentedon Jun 25, 2018
@rullzer I guess this is nothing for 14 anymore, right?
rullzer commentedon Jun 25, 2018
Correct. I would love to have this in. but it needs proper planning yes.
mario commentedon Dec 11, 2018
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 commentedon Dec 1, 2020
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:
newhinton commentedon Dec 28, 2021
@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:
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 commentedon Sep 10, 2023
@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:
It cannot:
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 commentedon Sep 10, 2023
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)