Proposal: move bot tokens to OAuth using web hooks

[dead-claudia]

The idea is this: authenticated bots are normally trusted and few in number. But there's security risks in granting them app passwords, and refresh tokens can only extend the session for up to a year. Webhooks can solve that problem for most bots by shifting the root of trust to the PDS. And the few remaining ones can just use OAuth 2 and stuff like Device Authorization - 1-year sessions aren't a big deal, and if it's uptime-critical, it's critical enough to have a web service set up to push stuff to it.

The flow would look like this for each webhook:

This would use PQXDH to start, but can be readily altered to use any key exchange protocol that's structurally similar to Diffie-Hellman.

1. User gets refresh token (read: shared parameters) from webhook supplier over a secure channel (read: HTTPS).
2. User adds webhook URL + initial refresh token to PDS.
3. Repeat daily:
   1. PDS generates secret A using refresh token, sends {I, A} where I is the user identity to server in request. I is used by the server to look up its own shared parameters.
   2. Server generates secret B using token, sends {B; KS = encrypt(K, {S; D})} with shared secret S, server encryption key K, and current date D to PDS in response. PDS and server now share prospective secret S.

      KS is used to keep it fully stateless.

   3. PDS sends {N; KS; encrypt(S, {N, access_token})} with nonce N to server in request header.
   4. If server matches both Ns in request, finds the current date in decrypted KS is at most, say, 5 minutes old, and sees that S is not in expiry list, server adds S to expiry list with appropriate TTL, replaces the access token, and sends 200 response to PDS. If S is in the expiry list, a 200 is returned, but nothing is done. Otherwise, it returns a 403 response.

      The second part is to better tolerate retries

   5. If PDS receives 200 or 403 response, PDS revokes old access token.

Both requests may be made over plaintext HTTP or encrypted HTTPS. The initial refresh token must be sent over HTTPS, however.

Threat model

• Request in steps 3.1/3.2 is intercepted and replayed by Eve: Server sends B, but Eve doesn't know S, and thus the server responds with 403 in step 3.4.
• Request in steps 3.1/3.2 is replayed by Eve repeatedly in a DoS attempt: Server generates and sends B. Server does not add any new state.
• Request in steps 3.3/3.4 is intercepted and replayed by Eve within 5 minutes: Server detects replay by seeing it's in the expiry list and rejects the attempt.
• Request in steps 3.3/3.4 is replayed by Eve repeatedly within initial 5 minute window in DoS attempt: Server detects replay by seeing it's in the expiry list and ignores the attempt. State does not grow.
• Request in steps 3.3/3.4 is intercepted and replayed by Eve after 5 minutes: Server rejects the attempt as the token is too old.
• Request in steps 3.3/3.4 is replayed by Eve repeatedly after 5 minutes in DoS attempt: Server rejects the attempt as the token is too old.