Skip to content

Commit 72e694b

Browse files
turt2liverichvdh
andauthored
MSC4126: Deprecation of query string auth (#4126)
* MSC: Deprecation of query string auth * Update proposals/4126-deprecate-query-string-auth.md Co-authored-by: Richard van der Hoff <[email protected]> --------- Co-authored-by: Richard van der Hoff <[email protected]>
1 parent 2daf5b3 commit 72e694b

File tree

1 file changed

+74
-0
lines changed

1 file changed

+74
-0
lines changed
Lines changed: 74 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,74 @@
1+
# MSC4126: Deprecation of query string auth
2+
3+
Presently, the Client-Server API allows clients to provide their access token via the `Authorization`
4+
request header or via an `access_token` query string parameter, described [here](https://spec.matrix.org/v1.10/client-server-api/#using-access-tokens).
5+
Clients are already encouraged to use the header approach, though the query string option exists for
6+
largely backwards compatibility reasons.
7+
8+
The query string approach is subject a number of security, usability, and practical concerns, discussed
9+
on [matrix-spec#1780](https://github.com/matrix-org/matrix-spec/issues/1780):
10+
11+
* The query string of an HTTP request is often logged by the client itself, middleware reverse proxy,
12+
and application/homeserver as well. Though some of these layers may be aware of this issue, they
13+
can trivially accidentally break to log sensitive credentials again. By contrast, headers are not
14+
typically logged by default.
15+
16+
* Users often copy and paste URLs from their clients to either get support or provide direct links
17+
to content/media. While the media angle is largely expected to be resolved with [MSC3916](https://github.com/matrix-org/matrix-spec-proposals/pull/3916),
18+
users are currently able to right click images in their client and copy the URL - if this URL
19+
includes authentication in the query string, the user will likely end up disclosing their access
20+
token. The same scenario applies when copy/pasting request logs out of a client when getting
21+
support.
22+
23+
* Having two ways of doing things could lead to compatibility issues, where a client using the query
24+
string approach is tried against a server which only supports the header. The client ends up not
25+
working, leading to subpar user experience.
26+
27+
* Most clients have already adopted the header approach, largely forgetting that the query string
28+
even exists. Continuing to support the query string option leaves some maintenance burden for what
29+
is effectively unused code.
30+
31+
* Matrix has [decided](https://matrix.org/blog/2023/09/matrix-2-0/) to adopt OIDC for authentication,
32+
which is based on OAuth 2.0, which [advises against](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.3.2)
33+
the query string approach.
34+
35+
With these conditions in mind, this proposal sets the query string approach on a path towards removal
36+
from the Matrix specification. This affects the Client-Server API and [Identity Service API](https://spec.matrix.org/v1.10/identity-service-api/#authentication)
37+
as both support the approaches described above.
38+
39+
## Proposal
40+
41+
For both the Client-Server API and Identity Service API, the `access_token` query string authentication
42+
parameter becomes *deprecated*, and SHOULD NOT be used by clients (as already stated in the specification).
43+
Deprecation is required for at least 1 spec version before removal under the [deprecation policy](https://spec.matrix.org/v1.10/#deprecation-policy).
44+
45+
Removal from the specification requires a second MSC and at least 1 specification release to pass. This
46+
is currently described as [MSC4127](https://github.com/matrix-org/matrix-spec-proposals/pull/4127).
47+
48+
## Potential issues
49+
50+
Clients which rely on the query string approach may stop working. This is considered acceptable for
51+
the purposes of this MSC.
52+
53+
## Alternatives
54+
55+
Most alternatives are not practical as they would maintain the security risk described in the introduction
56+
for this proposal.
57+
58+
Alterations to the deprecation policy may be discussed in a future MSC to make this sort of removal
59+
easier.
60+
61+
## Security considerations
62+
63+
Security considerations are described throughout this proposal.
64+
65+
## Unstable prefix
66+
67+
This proposal cannot feasibly have an unstable prefix. Clients are already discouraged from using
68+
query string authentication and should switch to `Authorization` as soon as possible, regardless of
69+
this MSC.
70+
71+
## Dependencies
72+
73+
This MSC has no direct dependencies itself. [MSC4127](https://github.com/matrix-org/matrix-spec-proposals/pull/4127)
74+
requires this MSC to land first.

0 commit comments

Comments
 (0)