feat(auth): store scopes on app passwords

[pringelmann]

• closes Scoped app passwords: store scopes #65525
• Ref Allow to restrict app password data access #2866

Summary

First step towards limited app passwords: a token can now carry a list of scopes. This PR only stores them. Apart from files access nothing enforces them yet, and there's no UI.

How scopes work

• Stored as a scopes key in the existing scope JSON column, so no migration
• OAuth-style names, defined by the app that owns the data: files:read, files:share in files, calendar:read, contacts:write etc. in dav
• Each scope stands on its own. Files are the exception: every files scope needs files:read, and files:read needs files:write until read-only files exist
• No scopes key means full access. That's every existing token, unchanged
• Empty list or anything malformed means no access
• Existing filesystem flag stays and is derived from files:read, so code reading it keeps working
• Per-app scopes come later (app:<appid>)

Change description

• A new internal helper reads and validates the scope list
• The files access check uses it for tokens that have scopes
• Saving a token no longer wipes its scopes. Before, every save replaced the stored permissions with the single filesystem flag sent by the browser. Now the server merges the change, ignores that flag on scoped tokens and only checks the shape of the list. Setting scopes to null resets the token to full access
• The occ token list shows the scopes

Next step

Enforcement on routes and DAV, then the access picker in Settings.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI (tests, reviewed)

[nickvergessen]

Not seeing it here in the diff, so I'm asking. Some things from filesystem e.g. appdata_* need to be always/frequent loadable, e.g. to load identity proof and check for updates, etc.

The other thing I'm wondering is how we could potentially improve the situation for e.g. mobile apps that try to render notifications/activity. It seems they would need at least *:read for all apps/scopes that potentially create activity/notifications as otherwise their resource should not be loadable and they would not be able to render them?

But maybe that is not the idea for now and you simply would use an unscoped token for such cases.

Otherwise while I didn't check the tests files, the general approach looks like we are going into the right direction, so I'm in

[pringelmann]

Not seeing it here in the diff, so I'm asking. Some things from filesystem e.g. appdata_* need to be always/frequent loadable, e.g. to load identity proof and check for updates, etc.

The other thing I'm wondering is how we could potentially improve the situation for e.g. mobile apps that try to render notifications/activity. It seems they would need at least *:read for all apps/scopes that potentially create activity/notifications as otherwise their resource should not be loadable and they would not be able to render them?

But maybe that is not the idea for now and you simply would use an unscoped token for such cases.

Otherwise while I didn't check the tests files, the general approach looks like we are going into the right direction, so I'm in

Thanks!

• The scope only gates the user's mounts, appdata is on the root storage and stays loadable. Same path as today's tokens with filesystem access turned off.
• Mobile/desktop: yes, those keep using unscoped tokens from login flow. Scopes are opt-in for scripts and integrations. A notifications:read option is planned for the scope picker UI, but rendering the resources would still need their app's scope, so full native clients stay on All access. Letting clients request scopes during login flow could be a later follow-up but is not planned for 36.