fix(auth): Include state in authentication requests

[jan-auer]

Changes the authentication payloads so that Sentry can authenticate without keeping state between the request and response API calls. This fixes a range of issues with the former authentication system.

Issues

• Only one Relay could use the same identifier. While this was intended, it introduced a race condition and DoS vector to deny authentication if multiple Relays authenticate concurrently with the same identifier. In the worst case, an attacker could prevent authentication using replay attacks.
• The upstream was required to keep state between the register and response calls. Spamming the upstream with register requests would result in increased resource usage over time.
• The random token created by the upstream was enforced at no point. This means that the downstream Relay could have swapped the token and still succeed with registration.

Changes

This change introduces RegisterState, a data container that is signed with a secret by the upstream. As it contains the public key and a timestamp, it ensures that the downstream cannot tamper with the state or use another Relay's token. Since the public key of the state is also used to verify the Relay request signature, the upstream can rely on the state without keeping caches. By encoding the state into the token, the HTTP API remains backwards compatible.

In addition to this, the default challenge TTL has been reduced from 15 minutes to 60 seconds.

Release

This change contains breaking changes to the Python API and requires a minor bump of the sentry_relay library. It is backwards compatible on the HTTP API. After updating in Sentry, old Relays will also use the new authentication system.

Deployment

This change can be deployed independently to Sentry and Relay in no particular order. Updating the library in Sentry will require code changes.

There is a minimal potential for breakage if Relays are authenticating while Sentry is being deployed. However, Relays will retry on authentication failure and as such, the condition resolves automatically as soon as the deployment finishes.