From a345b367ad25e3e4e74f3d5be67e6034ad55f579 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 24 Oct 2020 18:25:40 +0300 Subject: [PATCH 1/3] Proposal to fix homeserver -> appservice authorization Signed-off-by: Tulir Asokan --- proposals/2832-appservice-auth-fix.md | 37 +++++++++++++++++++++++++++ 1 file changed, 37 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 0000000000..c7a5f327af --- /dev/null +++ b/proposals/2832-appservice-auth-fix.md @@ -0,0 +1,37 @@ +# HS -> AS 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 deprecated and homeservers are encouraged +to use the `Authorization` header with `Bearer ` as the value when +sending transactions or other requests to application services. + +Application services MUST support checking the access token from the header. +Appservices SHOULD still support the old query param auth, but it is not +required, as there are no cases where a homeserver is unable to set HTTP +request headers. + +### Transition to auth header +Similarly to how [legacy routes](https://matrix.org/docs/spec/application_service/r0.1.2#legacy-routes) +work in the appservice spec, homeservers should prefer using the authorization +header, but fall back to the query parameter if the appservice returns a status +code indicating invalid auth (401 or 403). + +## Security considerations +Not fixing this causes access tokens to be logged in many bridges. + +## Alternatives +The transition could be done differently, e.g. with an appservice registration +field or homeserver config. Some sort of version identifier in appservice +registrations would be the optimal solution (define that after vX, auth always +uses the header), but such an identifier does not currently exist. + +## Unstable prefix +The authorization header is already used in the client-server spec, and an +unstable prefix would just unnecessarily complicate things. If the transition +is decided to be done with an appservice registration field, then that field +could have an unstable prefix. From ab408ddedbb44b3636574225b705708de0bf5f29 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Thu, 9 Jun 2022 18:25:35 +0100 Subject: [PATCH 2/3] Remove query parameter entirely instead of deprecating it Signed-off-by: Tulir Asokan --- proposals/2832-appservice-auth-fix.md | 31 ++++++++++----------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/proposals/2832-appservice-auth-fix.md b/proposals/2832-appservice-auth-fix.md index c7a5f327af..e179c2ff21 100644 --- a/proposals/2832-appservice-auth-fix.md +++ b/proposals/2832-appservice-auth-fix.md @@ -6,32 +6,23 @@ and it still requires using the archaic query parameter when the homeserver pushes transactions to the appservice. ## Proposal -The `access_token` query parameter is deprecated and homeservers are encouraged -to use the `Authorization` header with `Bearer ` as the value when -sending transactions or other requests to application services. +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. -Application services MUST support checking the access token from the header. -Appservices SHOULD still support the old query param auth, but it is not -required, as there are no cases where a homeserver is unable to set HTTP -request headers. - -### Transition to auth header -Similarly to how [legacy routes](https://matrix.org/docs/spec/application_service/r0.1.2#legacy-routes) -work in the appservice spec, homeservers should prefer using the authorization -header, but fall back to the query parameter if the appservice returns a status -code indicating invalid auth (401 or 403). +### 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 -The transition could be done differently, e.g. with an appservice registration -field or homeserver config. Some sort of version identifier in appservice -registrations would be the optimal solution (define that after vX, auth always -uses the header), but such an identifier does not currently exist. +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. If the transition -is decided to be done with an appservice registration field, then that field -could have an unstable prefix. +unstable prefix would just unnecessarily complicate things. From 3c41e0e1557613c924b0703c2a4454686b663c4e Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Fri, 10 Jun 2022 12:05:24 +0100 Subject: [PATCH 3/3] Update title Co-authored-by: Jonathan de Jong --- proposals/2832-appservice-auth-fix.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2832-appservice-auth-fix.md b/proposals/2832-appservice-auth-fix.md index e179c2ff21..412b4d0367 100644 --- a/proposals/2832-appservice-auth-fix.md +++ b/proposals/2832-appservice-auth-fix.md @@ -1,4 +1,4 @@ -# HS -> AS authorization header +# 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