Use something more secure than bearer tokens for auth

[richvdh]

moving access_tokens to the http headers mitigated it, but it's still quite easy to leak an access_token, in which case, you lose. Perhaps we should consider using something like OAuth 1 signatures, like twitter: https://developer.twitter.com/en/docs/basics/authentication/guides/creating-a-signature

[richvdh]

Another alternative is access_tokens that actually expire, or which have limited powers.

[cuibonobo]

I'm interested in this also. My concern is that logging in to a 3rd party app gives them access to all of my account data. I would be particularly interested in restricting apps to certain rooms or message types.

[richvdh]

It's worth noting that OAuth2 deliberately replaced OAuth1's signatures with bearer tokens, basically because signatures were a pita to work with. Maybe it's better just to limit the power (ie, scope) and lifetime of access tokens.

[richvdh]

related: #636

[hughns]

Some related activity:

• Time limited tokens: MSC2918: Refresh tokens matrix-spec-proposals#2918

• Access tokens with limited scope: MSC2967: API scopes matrix-spec-proposals#2967

• DPoP as replacement for Bearer tokens

  There is an extension to OAuth2 called DPoP which introduces a new type of token that is tied to a private key that must also be present at the time authentication is done: RFC9449.

  As far as I am aware there is no MSC for this yet but would be implemented after migrating to auth delegated via OIDC: MSC2964: Usage of OAuth 2.0 authorization code grant and refresh token grant matrix-spec-proposals#2964

[richvdh]

vaguely related: #1780