Move access_tokens out of query params (SYN-299)

[matrixbot]

Using access_tokens in query params is really quite insecure. We should do some combination of:

• Allow access_token in header
• Use a hmac scheme with and/or without expiration.

(Imported from https://matrix.org/jira/browse/SYN-299)

(Reported by @erikjohnston)

[matrixbot]

Jira watchers: @erikjohnston @richvdh

[matrixbot]

Links exported from Jira:

relates to SPEC-112
relates to #1403
relates to SYN-259

[matrixbot]

We now use macaroons, but the token is still in the query param, so presumably still suffers the same problems

-- @richvdh

[matrixbot]

(copied from SPEC-112)

So, this bug had a few references to Macaroons, but I feel that none of the posts that did so explained how Macaroons help - so I'll try and do so.

The really nice thing with Macaroons is that anyone can further constrain them, but nobody can remove a constraint once it's added. This allows the client to constrain the macaroon sent back to the server to a very short lifetime (on the order of seconds), while the one it actually holds may have a very long validity period indeed. If anyone sniffs the in-flight Macaroon, it will (by and large) be useless too soon to do them any good.

In addition, it can be constrained to the operation in question (if Synapse supported such caveats), so the sniffed macaroon would (say) only be usable for sending messages (and not state events), or perhaps even only to a specific room.

It can also be constrained to the user's external IP, which helps even more.

This would (partially) resolve #1290, too, so I'm copying it there, although TBH the right solution to that is probably "Authorization: Macaroon "

-- Alex Elsayed

[richvdh]

I believe this was fixed by #1098.