We need to reconsider whether to support refresh tokens.

[ara4n]

We removed refresh tokens from the spec in matrix-org/matrix-spec-proposals#1204 because a) nothing had implemented them despite them being specced for a year or so, b) there were doubts on whether they actually provided much benefit.

Since then, we've become aware of at least 2 projects built on Matrix who have chosen to re-add refresh tokens in their implementations as a custom addition to the protocol. The rationale is to avoid you ending up leaving a potential trail of access_tokens all over the place (e.g. in client local storage; http logs; server DBs; shell history) which have an infinite lifespan unless explicitly expired, and so could be used to compromise your account if discovered by an attacker even if they were years old.

Instead, if access_tokens had a finite life, and instead the server could expire them on demand and require the client to present a one-time use refresh_token to claim a new access_token, then old access_tokens left lying around the place become a lot less useful... and likewise old refresh_tokens. The attacker would have to intercept both the current refresh_token and access_token to compromise an account, and given refresh_tokens would be rarely used (unlike access_tokens, which decorate every request), this feels like it might provide a modest improvement in security.

[ara4n]

@richvdh says:

though I think that if we're worrying about the security of access tokens, switching to a mac-based system instead of bearer tokens would give a better return on investment

[richvdh]

@richvdh says:

though I think that if we're worrying about the security of access tokens, switching to a mac-based system instead of bearer tokens would give a better return on investment

OAuth2 apparently reached the opposite conclusion...

Anyway, if we're doing this, we might go the whole hog and switch to OAuth2: https://github.com/matrix-org/matrix-doc/issues/2615

[richvdh]

I think this is fixed by MSC2918 and #1056.