Change Details

See PHI613. This is a request for two specific, reasonable features for managing API tokens: - Allow API tokens to have a name, so it's easier to keep track of which token is being used for what (e.g., "Chromebook", "Macbook", "Webhook Bot"). - Show when a token was last used, so unused tokens can more confidently be deleted. Some adjacent/future work which may make sense to do here or plan around doing in the future: - See PHI603, which touches on security concerns related to compromised backups. It would be nice to optionally store token digests only, not the actual tokens, so that an attacker who gains a compromised backup can not use recovered tokens to execute API calls against production. We could very reasonably do this by default for `arc` tokens, which tend to be one-time use. - Address pinning ("this token is valid only from remote address X.Y.Z.Q/16"). - Granular permissions (also OAuth / SSH), e.g. "read-only token", "bot token that can only do task stuff", etc. I think that address pinning and granular permissions are probably larger projects that make sense as part of some future project which defines a bunch of "Authentication Method Access Control Options" and can be associated with an SSH key, an OAuth token, or a Conduit API token. So I'd say we shouldn't build these here, but some of the work we do will prepare us for them. We probably can reasonably at least add some digest support here. --- Much of this will parallel similar work on SSH keys a couple of years ago in T10917, which turned them into roughly similar modern objects, although the goal there was to generate normal transactional mail for edits. That task and the associated changes (and the current state of SSH key management in the UI) may be informative. --- Implementation pathway is probably something like: - Give `ConduitToken` a real PHID and migrate existing tokens to have one. - Give it transactions and implement `TransactionInterface`, `Editor`, etc. - Make the UI work a bit more like SSH keys do, so we have room to add an edit link, review transaction history, etc. - Add a "name", add support for editing it. Then: - Add an `authenticationKeyPHID` or similar to `ConduitMethodCallLog` and start recording Token/SSH PHIDs where reasonable. - In the UI, query the `MethodCallLog` table and render "Last used X days ago" or "last used more than <garbage collection interval> days ago" based on what you get back. - Link to the MethodCallLog so users can see what calls the token has been used for. For digests: - Add a `tokenDigest` column to `Token`. - Begin populating it with `PhabricatorHash::digestWithNamedKey(...)` of the token, and migrate existing tokens. - Make `TokenQuery->withTokens()` digest the tokens and query against `tokenDigest` instead. - The unique key should move to the digest column, not the token column. - Make the token column nullable. - Now we're prepared to start actually throwing away tokens. This might be easy to put into practice on the `arc install-certificate` workflow. For manually generated tokens, we could add a UI action like "dispose of token", perhaps.

See PHI613. This is a request for two specific, reasonable features for managing API tokens: - Allow API tokens to have a name, so it's easier to keep track of which token is being used for what (e.g., "Chromebook", "Macbook", "Webhook Bot"). - Show when a token was last used, so unused tokens can more confidently be deleted. Some adjacent/future work which may make sense to do here or plan around doing in the future: - See PHI603, which touches on security concerns related to compromised backups. It would be nice to optionally store token digests only, not the actual tokens, so that an attacker who gains a compromised backup can not use recovered tokens to execute API calls against production. We could very reasonably do this by default for `arc` tokens, which tend to be installed in only one location. - Address pinning ("this token is valid only from remote address X.Y.Z.Q/16"). - Granular permissions (also OAuth / SSH), e.g. "read-only token", "bot token that can only do task stuff", etc. I think that address pinning and granular permissions are probably larger projects that make sense as part of some future project which defines a bunch of "Authentication Method Access Control Options" and can be associated with an SSH key, an OAuth token, or a Conduit API token. So I'd say we shouldn't build these here, but some of the work we do will prepare us for them. We probably can reasonably at least add some digest support here. --- Much of this will parallel similar work on SSH keys a couple of years ago in T10917, which turned them into roughly similar modern objects, although the goal there was to generate normal transactional mail for edits. That task and the associated changes (and the current state of SSH key management in the UI) may be informative. --- Implementation pathway is probably something like: - Give `ConduitToken` a real PHID and migrate existing tokens to have one. - Give it transactions and implement `TransactionInterface`, `Editor`, etc. - Make the UI work a bit more like SSH keys do, so we have room to add an edit link, review transaction history, etc. - Add a "name", add support for editing it. Then: - Add an `authenticationKeyPHID` or similar to `ConduitMethodCallLog` and start recording Token/SSH PHIDs where reasonable. - In the UI, query the `MethodCallLog` table and render "Last used X days ago" or "last used more than <garbage collection interval> days ago" based on what you get back. - Link to the MethodCallLog so users can see what calls the token has been used for. For digests: - Add a `tokenDigest` column to `Token`. - Begin populating it with `PhabricatorHash::digestWithNamedKey(...)` of the token, and migrate existing tokens. - Make `TokenQuery->withTokens()` digest the tokens and query against `tokenDigest` instead. - The unique key should move to the digest column, not the token column. - Make the token column nullable. - Now we're prepared to start actually throwing away tokens. This might be easy to put into practice on the `arc install-certificate` workflow. For manually generated tokens, we could add a UI action like "dispose of token", perhaps.

See PHI613. This is a request for two specific, reasonable features for managing API tokens: - Allow API tokens to have a name, so it's easier to keep track of which token is being used for what (e.g., "Chromebook", "Macbook", "Webhook Bot"). - Show when a token was last used, so unused tokens can more confidently be deleted. Some adjacent/future work which may make sense to do here or plan around doing in the future: - See PHI603, which touches on security concerns related to compromised backups. It would be nice to optionally store token digests only, not the actual tokens, so that an attacker who gains a compromised backup can not use recovered tokens to execute API calls against production. We could very reasonably do this by default for `arc` tokens, which tend to be one-time useinstalled in only one location. - Address pinning ("this token is valid only from remote address X.Y.Z.Q/16"). - Granular permissions (also OAuth / SSH), e.g. "read-only token", "bot token that can only do task stuff", etc. I think that address pinning and granular permissions are probably larger projects that make sense as part of some future project which defines a bunch of "Authentication Method Access Control Options" and can be associated with an SSH key, an OAuth token, or a Conduit API token. So I'd say we shouldn't build these here, but some of the work we do will prepare us for them. We probably can reasonably at least add some digest support here. --- Much of this will parallel similar work on SSH keys a couple of years ago in T10917, which turned them into roughly similar modern objects, although the goal there was to generate normal transactional mail for edits. That task and the associated changes (and the current state of SSH key management in the UI) may be informative. --- Implementation pathway is probably something like: - Give `ConduitToken` a real PHID and migrate existing tokens to have one. - Give it transactions and implement `TransactionInterface`, `Editor`, etc. - Make the UI work a bit more like SSH keys do, so we have room to add an edit link, review transaction history, etc. - Add a "name", add support for editing it. Then: - Add an `authenticationKeyPHID` or similar to `ConduitMethodCallLog` and start recording Token/SSH PHIDs where reasonable. - In the UI, query the `MethodCallLog` table and render "Last used X days ago" or "last used more than <garbage collection interval> days ago" based on what you get back. - Link to the MethodCallLog so users can see what calls the token has been used for. For digests: - Add a `tokenDigest` column to `Token`. - Begin populating it with `PhabricatorHash::digestWithNamedKey(...)` of the token, and migrate existing tokens. - Make `TokenQuery->withTokens()` digest the tokens and query against `tokenDigest` instead. - The unique key should move to the digest column, not the token column. - Make the token column nullable. - Now we're prepared to start actually throwing away tokens. This might be easy to put into practice on the `arc install-certificate` workflow. For manually generated tokens, we could add a UI action like "dispose of token", perhaps.