Add Conduit Tokens to make authentication in Conduit somewhat more sane
39f2bbaeea1b
Actions

Description

Add Conduit Tokens to make authentication in Conduit somewhat more sane

Summary:
Ref T5955. Summary of intended changes:

Improve Granularity of Authorization: Currently, users have one Conduit Certificate. This isn't very flexible, and means that you can't ever generate an API token with limited permissions or IP block controls (see T6706). This moves toward a world where you can generate multiple tokens, revoke them individually, and assign disparate privileges to them.

Standardize Token Management: This moves Conduit to work the same way that sessions, OAuth authorizations, and temporary tokens already work, instead of being this crazy bizarre mess.

Make Authentication Faster: Authentication currently requires a handshake (conduit.connect) to establish a session, like the web UI. This is unnecessary from a security point of view and puts an extra round trip in front of all Conduit activity. Essentially no other API anywhere works like this.

Make Authentication Simpler: The handshake is complex, and involves deriving hashes. The session is also complex, and creates issues like T4377. Handshake and session management require different inputs.

Make Token Management Simpler: The certificate is this huge long thing right now, which is not necessary from a security perspective. There are separate Arcanist handshake tokens, but they have a different set of issues. We can move forward to a token management world where neither of these problems exist.

Lower Protocol Barrier: The simplest possible API client is very complex right now. It should be curl. Simplifying authentication is a necessary step toward this.

Unblock T2783: T2783 is blocked on nodes in the cluster making authenticated API calls to other nodes. This provides a simpler way forward than the handshake mess (or enormous-hack-mess) which would currently be required.

Test Plan: