Consider replacing our auth system with OAuth2

[richvdh]

Over the years, we've evolved our own authentication/authorization system in the shape of the login api, user-interactive auth, access_tokens, and soft logout.

The current implementation is largely functional, but it does duplicate much of what OAuth2 does, and as ever, particularly when considering security-sensitive subjects, it's better to use standardised protocols (even when they are as sprawling as OAuth2) than to roll your own.

In addition, there are a bunch of things which we could improve in the current system, but which OAuth2 already has answers for.

I've started a document at https://docs.google.com/document/d/1e-ZqghugaHaRukb88PRmPFdm24-y-Ea5ka89IrAEZ7s to collect notes on what might be better with OAuth2, and how it might work in practice.

[sandhose]

For Synapse, this is how I see it. There are two scenarios:

• Synapse acts as a authorization server (AS) in simple deployments, with whatever password backend. It stores its own access tokens and manages them, so it can verifies them just by checking the DB
• auth is delegated to another authorization server. In that case, Synapse acts as a resource server and needs to check somehow the validity of the access tokens presented. To do that, there are multiple mechanisms that exists:
  • the access token is a (short-lived) JWT, verifiable by its signature: https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04 (it's a draft, but implemented by a lot of AS)
  • the AS implements the OAuth2 introspection endpoint and that endpoint is accessible by Synapse. In that scenario, the token is opaque to Synapse, and can POST the token to that endpoint to check what scopes are allowed
  • if neither of those are available, if the AS is OpenID Connect-compliant and the token has the openid scope, Synapse can query the userinfo endpoint with the token. It can't check for scopes there, but at least it can check for token validity.

Delegating the auth to a third party authorization server would make it a lot easier to implement policies and auth methods (2FA, FIDO, passwordless logins) specific to a deployment without having to implement them in Synapse. A lot of those identity providers have years of development and security hardening that would benefit many deployments.

---

Another thing to consider is to keep a lot of the existing login logic while slowly implementing most of OAuth2. As an access token is bound to a specific client, existing clients using the existing login mechanisms would be identified as a special "legacy" client that issues token without expiration (because current access tokens don't have expiration nor any mechanism to renew them).
In this case, it would be even possible for Synapse to issue tokens from another AS using the password grant (if supported by the AS)

---

Last but not least, it would be interesting to see what it means for integrations. I've seen in Synapse's code that it implements a basic OIDC userinfo endpoint because of integrations ; there is probably something to investigate there.

[Sorunome]

oauth2 could be a uia stage, but uia allows greater flexibility.

At work we use it for additional verification steps to only allow login to "good" servers from our app

[joepie91]

and as ever, particularly when considering security-sensitive subjects, it's better to use standardised protocols (even when they are as sprawling as OAuth2) than to roll your own.

That's not quite right - the good practice is to use battle-tested protocols. Unfortunately, that set does not fully overlap with "standardized protocols", and in fact quite a few standardized protocols designed by non-cryptographers are infamous for bad cryptography and insecure API design (see eg. the history of weird and broken crypto in WEP/WPA).

Notably, JWT is terrible from a security perspective and likewise OAuth2 has been frequently criticized by people in the security community for having a high degree of complexity, resulting in a risky attack surface.

I honestly don't think it's a good idea to use JWT or OAuth2 for usecases other than those where they are necessary for interoperability reasons.

[richvdh]

Quick update: this project is progressing, as we get time.

• MSC2964 is an overview of the design
• https:/matrix-org/matrix-authentication-service is a working OAuth2 authentication server, intended to be deployed alongside homeservers which will delegate their authentication to it
• Draft: OIDC native login element-hq/hydrogen-web#660 is the initial work required to update Hydrogen to use the new mechanism.

[hughns]

I've been working on this area of Matrix for a little while now and on revisiting this issue I wanted to share what I believe are the main reasons for considering this change.

One thing to note is that I don't see change as being about replacing UIA with OIDC, but instead allowing homeservers to delegate auth duties to another entity.

By adopting such an architecture I see that there can be benefits to the ecosystem on multiple fronts -

It allows us to benefit from security protocols that have been battle-tested by many more people than just in the Matrix ecosystem.

It reduces the scope of the Client-Server spec freeing up spec time to focus on it's USPs (e.g. decentralised messaging).

From a homeserver implementor point of view it reduces the codebase which should:

• improve the maintainability of said homeserver codebases
• make it easier for new homeserver implementations to be created as they no longer have to implement a (relatively) complicated area of the spec
• make it easier for existing homeserver implementations to implement the latest auth features (e.g. Dendrite nor Conduit currently support SSO)

From a Matrix client implementor point of view:

• complexity is reduced as UIA no longer needs to be implemented
• you can use off-the-shelf implementations of clients (e.g. https://appauth.io/ has been used for some very rapid prototyping by @sandhose)
• new authentication mechanisms (2FA, WebAuthn etc.) come for "free"