From 3297d37770c5d103ae1118d2100b8b8ed38fb766 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 17 Jul 2022 21:47:50 +0300 Subject: [PATCH] MSC2832: HS -> AS authorization header (#2832) * Proposal to fix homeserver -> appservice authorization Signed-off-by: Tulir Asokan * Remove query parameter entirely instead of deprecating it Signed-off-by: Tulir Asokan * Update title Co-authored-by: Jonathan de Jong Co-authored-by: Jonathan de Jong --- proposals/2832-appservice-auth-fix.md | 28 +++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 proposals/2832-appservice-auth-fix.md diff --git a/proposals/2832-appservice-auth-fix.md b/proposals/2832-appservice-auth-fix.md new file mode 100644 index 000000000..412b4d036 --- /dev/null +++ b/proposals/2832-appservice-auth-fix.md @@ -0,0 +1,28 @@ +# MSC2832: Homeserver -> Application Service authorization header +Most of the auth tokens in the spec are passed in the `Authorization` header, +with the `access_token` query parameter supported for backwards-compatibility. +For some reason, the application service spec was not updated in the same way +and it still requires using the archaic query parameter when the homeserver +pushes transactions to the appservice. + +## Proposal +The `access_token` query parameter is removed from all requests made by the +homeserver to appservice and is replaced with the `Authorization` header with +`Bearer ` as the value. + +### Backwards-compatibility +Homeservers which want to support old spec versions in the appservice API may +send both the query parameter and header. Similarly, appservices may accept the +token from either source. + +## Security considerations +Not fixing this causes access tokens to be logged in many bridges. + +## Alternatives +We could add a way for appservices to explicitly specify which spec version +they want in order to implement backwards-compatibility without sending both +tokens. + +## Unstable prefix +The authorization header is already used in the client-server spec, and an +unstable prefix would just unnecessarily complicate things.