The manage token page allows a user to revoke webservice tokens and rss tokens:

/user/managetoken.php

But there are other token types that are broadly equivalent or worse in risk profile to rss tokens. So proposing that this page show all tokens, their ip restrictions and expiry and where you can revoke them all.

There could be some sort of callback or auto loaded class so that a core component or a plugin which uses login keys can easily augment the behavior, eg maybe it could declare that keys can be revoked but should not be visible, or declare a link to . All of the rss specific logic should be moved to use this so it's just another type of managed token with no special priority.

Also each key should have new fields which track when it was last used and what ip it was used from. Even with ip restriction these might be different as the ip restriction could be an ip range. We should also split this logging and most recent use out by user agent and not put it directly into the same table, this is so we can easily expose to the end user something like: 'This key is was used by Google Calendar in the last day, and by Nextcloud 3 days ago' and then the user can go: 'huh? I don't use nextcloud', and they can revoke the key and then go setup google again.

To some extent all of the following data tables do vaguely similar things storing secrets or keys or tokens which grant access to the users data and should be treated in similar ways and be visible and revokable.

mdl_sessions - web sessions

mdl_external_tokens - web services eg mobile app sessions

mdl_user_devices - mobile app push tokens

mdl_oauth2_*

mdl_user->secret (maybe?)

mdl_user_password_resets

mdl_messageinbound_*

mdl_user_private_key - rss, mobile qr login, 

mdl_met_session (maybe?)

There is also a deficiency in external_generate_token_for_current_user in that it only ever allows a single token to be generated for a user for a given service. If you have a user who has logged in using the mobile app on two devices then they should get two unique tokens in the same way they would get two unique sessions on the web but they don't. On this page you should be able to see each device and revoke them individually.

external_generate_token_for_current_user needs to be passed in some sort of context dependent unique identifier and maybe some nicer human readable info, eg on mobile it could be the device id and its make and model, or for some other service it could be its user agent and human readable version.