[Feature Request] occ command to manage user app passcodes

[mmattel]

This Feature Request is about to extend the ./occ user command to manage app passcodes

user:app-passcode <user> --list
user:app-passcode <user> --create <app-name>
user:app-passcode <user> --delete <app-name>

Intention:
Automation for rollouts especially in enterprises.

@patrickjahns @PVince81 @pmaier1 @hodyroff

[ownclouders]

GitMate.io thinks possibly related issues are #8569 (Feature requests), #12530 (Feature Request), #22635 (Feature Request: OCC Change Password Using Hash), #29960 ([Feature Request] extend ./occ user to list logged on users), and #14252 (feature request : Occ need new commands).

[hodyroff]

Hm, oAuth2 with proper management for admins is not sufficient? Why? There might be a good reason, please let me know.

[phil-davis]

--list will just list the "names" of the app passcodes (the actual values are encrypted) - I guess it would be useful to know what is there to delete.
--create will need to output the created app passcode, then the administrator will need to communicate it somehow to the user. Is there a use case example for when this would be used?
--delete would be useful so the administrator can delete app passcodes that are known to have been compromised, when the user themselves is not in a position to do it.

[PVince81]

or would it be enough to revoke all the tokens of the user in case the account is compromised ?

[mmattel]

maybe only a device got lost and you want to revoke access to that particular device only.
revoke all is possible but maybe too much

[pmaier1]

Actually OAuth2 is the way to go to provide such functionality in a proper, automated and standardized way. I'm aware that we need some enhancements to the OAuth2 implementation like an admin management interface (including occ commands) and also more granular options in the UI (e.g. ability to distinguish between particular clients). Considering the benefits of OAuth2 I'm very hesitant to invest in app passwords.

[patrickjahns]

@pmaier1
that is very short sighted - consider that webdav clients do not necessarily have oauth as authentication mechanism integrated (example: cadaver)
having app-passwords means to be able to use ownCloud as an storage integration that can be talked to by any webdav client without exposing your users password

it needs to be hover discussed, if for automation the cli is the way to go - or we rather invest in a proper API that provides this functionality

[pmaier1]

consider that webdav clients do not necessarily speak oauth.

I'm fully aware.

that is very short sighted

I consider our focus to be on the native clients which have OAuth2 support and would like to cover the mentioned requirements there first.

[stale]

This issue has been automatically closed.