Service auth method binding (lxm)

[dholms]

This iterates on our current service auth tokens by adding an additional claim (lxm or "lexicon method") to the JWT payload which "binds" a token to a given request. This is not intended as an endstate for authorization semantics, but rather an incremental improvement over the current situation that is forward-compatible with a couple possible plans for a more expressive authorization system.

This also introduces a random 128 bit (hex-encoded) nonce onto each signed token. As these tokens are intended to be single use, this allows a service to optionally implement reuse prevention

An example service auth token may look like:

{
  iss: "did:example:user",
  aud: "did:example:service",
  lxm: "com.atproto.repo.createRecord"
  nonce: "2ec15719a8ba82868f2506162541582f9462f3fdddb0ae4cee150e3031d01e97"
}

These tokens are backwards-compatible with existing services that do not do method checks. A service auth token with no lxm claim may still be used for simple authentication, but should not be used for any sensitive behavior or to perform actions on behalf of the user.

Alongside this, we also update com.atproto.server.getServiceAuth to take lxm as a parameter, as well as an optional exp time. This allows us to lower the access requirement for getServiceAuth such that app passwords are able to use the route. We perform an additional check within getServiceAuth to determine if the requester has the proper access level to receive a service auth token for the requested method. App passwords will not be able to request access to privileged methods such as DM-related methods.

This also enables uploadBlob to be called using a service auth token on behalf of a user. Only this user-facing route accepts service auth tokens for now but this can serve as a pattern for future routes.

---

Rollout plan:

• Deploy our PDSs & publish the PDS distribution with updated service auth creation code such that all generated service auth tokens include the relevant scope(s) (Service auth method binding - PDS #2668)
  • In this deploy we should continue requiring a "privileged" access token (ie not app password) in order to create any service auth (since Chat & Ozone are not deployed yet)
• Wait a few days to ensure PDSs update
• Deploy sensitive services including Ozone & Chat.
• Deploy an update to the PDS that allows app passwords to create service auth tokens
• Deploy less sensitive services such as Bsky Appview