MSC4108: Mechanism to allow OAuth 2.0 API sign in and E2EE set up via QR code - 2024 version of rendezvous

[hughns]

Tracking issue for the 2024 version of the rendezvous session from MSC4108.

Context

This is the implementation for the secure rendezvous session part of the 2024 version of MSC4108 which allows for Sign in with QR feature.

Important

This experimental feature is being superseded by an a feature tracked by #19434. But it is recommended to stay with this current version until MSC4108 is finalised.

Current design in Synapse

It is implemented as Twisted servlets in Rust.

Usage

Pre-requisites:

• OAuth 2.0 API needs to be enabled either via the matrix_authentication_service or the experimental_features.msc3861 configuration options

The feature is configured using:

experimental_features:
	msc4108_enabled: true

or

experimental_features
	msc4108_delegation_endpoint: https://example.com/rendezvous

Caveats to be aware of

• Limitations of the MSC:
  • the use of ETag headers can cause issues with proxies and load balancers. e.g. Link device QR code fails with 412 M_CONCURRENT_WRITE #18155
  • additional CORS headers may need to be allowed on proxies/load balancers
  • it is not tolerant to server and client clocks being out of sync: MSC4108 2024 version (Sign in with QR code): clock desynchronisation between client and homeserver causes rendezvous session to be immediately deleted and the login to fail matrix-org/matrix-js-sdk#5141
• Synapse implementation:
  • in progress rendezvous sessions are dropped during a server restart
  • currently restricted to the main process
  • no specific rate limit controls
  • maximum session duration is not configurable
  • the maximum concurrent sessions is not configurable

How do we know when to remove this

We can remove support for this once we land support for whatever the final version of MSC4108 ends up being + some time period to allow clients to catch up.