|
| 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