Decouple access token tracking from device tracking

[DMRobertson]

A step towards #51.

CREATE TABLE syncv3_sync2_tokens (
    token_hash TEXT NOT NULL PRIMARY KEY, -- SHA256(access token)
    user_id TEXT NOT NULL,
    device_id TEXT NOT NULL,  -- FK constraint to devices table?
    last_seen TIMESTAMP NOT NULL,
    token_encrypted TEXT NOT NULL
)

Use:

• When a new conn is made, lookup the (user, device) pair by token_hash.
  • Use this pair as the key within the proxy, to avoid confusing ourselves
  • If unknown, call /whoami to determine the (user, device) pair.
• Update the last_seen timestamp to now.

Rationale:

• Without separate token tracking, we, would have to assume one device has at most one access token in play. This opens us up to race conditions.
• Longer term, we want to support the prospect of a "long-lived token", or even making the proxy request tokens on the client's behalf.

Implementation:

• One-time migrate the existing access tokens from devices table. This requires many /whoami calls to fetch the actual device ID from the homeserver.
• Periodically clean out access tokens (from cache and DB). that haven't been used lately, say in a week. We would keep rows in the device table around though, for the since parameter in particular.
• Optimisation: cache the tokens table in memory. We'll have to make sure that any invalidations apply to the cache as well as the DB.
• Optimisation: only write the last_seen timestamp with coarse resolution, e.g. 24hr.

Questions:

• If the poller learns that a token has expired, should we record that fact? Otherwise we might expire a token only for the client to use it, meaning we'll make /whoami calls. Maybe a expired BOOLEAN NOT NULL field?

[kegsay]

If the poller learns that a token has expired, should we record that fact? Otherwise we might expire a token only for the client to use it, meaning we'll make /whoami calls. Maybe a expired BOOLEAN NOT NULL field?

Probably not as it hurts self-healing. If Synapse returns a 401/403 for some other reason and we mark the token as expired, but it isn't really, then we break the client until they refresh their token. If instead we don't mark it as expired, then yes we will stop polling due to the 401/403, but they can "kick" the server by using the token again, which will then hopefully return 200 OK when used again. The cost of this is a /whoami call but that feels fine to me.

[kegsay]

Optimisation: cache the tokens table in memory. We'll have to make sure that any invalidations apply to the cache as well as the DB.

Do we need to invalidate though? In the general case, expired tokens won't be used anymore by clients. We don't need to eagerly update the cache when we get 401/403d from a poller. This is similar to the above point, as it again allows clients to kick/refresh/reset things by using the token again (though in the general case we wouldn't expect them to). The risk with this though is that we are then creating >1 token which can be used to access the user's data, which is completely antithetical to refreshing tokens in the first place :/ bah.

[DMRobertson]

Plan to work on the dmr/oidc branch for this.

• Define new-style v2 tables and get the code to read/write to/from them OIDC: track tokens separately to devices #90
• Define new-style v3 tables and get the code to read/write to/from them OIDC: update sync3 tables #95
• Write one-off migration logic which gets us from old tables to new Migrate existing data to new schema on startup #98
  • Try it out on a backup of the database?
• Add specific test cases:
  • E2E test which ensures that refresh tokens work sensibly
  • E2E test of transaction id scoping, per Scope the connections to devices and not to a hash of the access token #51 (comment)