aggregator API: default to bearer tokens

[tgeoghegan]

Previously, the aggregator API assumed that any aggregator or collector auth tokens it was handling were AuthenticationToken::DapAuth. Janus must support those for the interop testing API and to work with Daphne, but generally, we prefer to use more boring Authorization: Bearer tokens. Certainly any tasks provisioned via the aggregator API and divviup-api should use bearer tokens.

With this PR, we augment the PostTaskReq and PostTaskResp messages so that they use AuthenticationToken to represent aggregator and collector tokens, meaning that on the wire, a token now looks like:

{
  "type": "Bearer",
  "token": "AAAAAAAAA<etc.>"
}

Also, when the aggregator API generates either kind of token, it now generates a bearer token. I'm not aware of any scenarios where we need to generate DapAuth tokens in the aggregator API so there is no affordance for requesting that kind of token.

See #472

[tgeoghegan]

Corresponding divviup-api change: divviup/divviup-api#247

[divergentdave]

I think we should avoid representing these tokens as base64 in some places and base64url in others.

A more flexible approach would be to not round-trip bearer tokens through either base64 or base64url, but instead validate that they match the syntax in RFC6750 when deserializing, store them as-is, and compare them as-is. This should be addressed separately, at any rate.

[tgeoghegan]

I agree with you that we need to be consistent about encodings. We previously discussed how we prefer unpadded Base64URL where possible, because:

• we are forced to use it to interpolate values into URLs
• it's more copy-pasteable than Base64 (whose alphabet contains /)

I had thought that the Authorization: Bearer header was the one place where tokens must be represented as plain Base64. For that reason, I have been insisting that we need to consider the canonical form of an authentication token to be the bytes, and then Base64 or unpadded Base64URL encodings are details of a particular serialization context.

However, I just noticed that I have misread RFC 6750 2.1: its grammar for the Authorization: Bearer scheme allows both the Base64 and Base64URL alphabets (and some extra symbols like . and ~).

I think that means we can use unpadded Base64URL everywhere: config files, JSON messages sent to APIs, and HTTP headers. Doing this would break existing clients/users of:

1. divviup-api
2. the Janus aggregator API
3. janus_cli's task provisioning subcommand
4. the Janus DAP API, if authenticated by bearer tokens instead of DAP-Auth-Token

But (1), (2) and (3) are broken by the recent changes anyway. And I'm pretty sure (4) doesn't exist, because the only external users of Janus that have existed so far have used DAP-Auth-Token. Meaning I think we can still change the representation of bearer tokens in HTTP headers without (further) breaking anyone.

Now, if unpadded Base64URL is permissible everywhere we need to transmit an authentication token, then that means that we can, as you suggest, treat them opaquely. In other words, we can start treating the unpadded Base64URL encoding of some bytes as the canonical form of the token.

Long story short: I want to implement your suggestion. I think this PR is the right place to do it, as well.

edit: I should acknowledge that several people, including jbr, have been telling me to do this for some time, but I was too dense and hung up on my incorrect understanding of RFC 6750 to listen.

[divergentdave]

nit: the token is now a composite value

Suggested change

	/// If this aggregator is the leader, this is the token to use to authenticate requests to
	/// the helper, as Base64 encoded bytes. If this aggregator is the helper, the value is
	/// `None`.
	/// If this aggregator is the leader, this is the token to use to authenticate requests to
	/// the helper. If this aggregator is the helper, the value is `None`.

[tgeoghegan]

Downgrading to a draft; I'll tinker with this while on trains next week.

[tgeoghegan]

We now use Base64URL unpadded everywhere, and this works in conjunction with the changes in divviup/divviup-api#247 to do an end to end test where we use the BYOHelper flow to pair aggregators, provision a task and then run an aggregation. This is ready for review.

[divergentdave]

While this will be a disruptive change, I think it will be a nice improvement to have all auth tokens have the same representation in memory, on the wire in DAP requests, on the wire in aggregator API requests, in YAML files, and on the command line. We should mention this in the next release's notes, and also communicate it to our partners that have currently deployed Janus for testing purposes. (for example, old task YAML files may no longer parse, bearer-type authentication tokens in a database would be interpreted differently when loading and will likely throw an error)

[divergentdave]

This would be a good place for a Cow<'_, str>, but it's moot because it'll likely get moved, cloned, or copied into a request structure.

[divergentdave]

We should use task.primary_aggregator_auth_token(), instead, which the last token in the list, not the first.

[divergentdave]

Same as below, task.primary_collector_auth_token()