|
| 1 | +# MSC2610: Remove `m.login.oauth2` User-Interactive Authentication type from the specification |
| 2 | + |
| 3 | +The client-server API specification |
| 4 | +[defines](https://matrix.org/docs/spec/client_server/r0.6.1#authentication-types) |
| 5 | +a number of "authentication types" for use with the User-Interactive |
| 6 | +Authentication protocol. |
| 7 | + |
| 8 | +Of these, `m.login.oauth2` is underspecified and of no |
| 9 | +real use. This MSC proposes removing them. |
| 10 | + |
| 11 | +## Proposal |
| 12 | + |
| 13 | +The definition of |
| 14 | +[OAuth2-based](https://matrix.org/docs/spec/client_server/r0.6.1#oauth2-based) |
| 15 | +authentication is incomplete. [OAuth2](https://oauth.net/2/) is best considered |
| 16 | +as a framework for implementing authentication protocols rather than a protocol |
| 17 | +in its own right, and this section says nothing about the grant types, flows |
| 18 | +and scopes which a compliant implemenation should understand. |
| 19 | + |
| 20 | +A better candidate for OAuth2-based authentication of matrix clients is via |
| 21 | +[OpenID Connect](https://openid.net/connect/), but this has already been |
| 22 | +implemented in Matrix via the `m.login.sso` authentication type. |
| 23 | + |
| 24 | +The `m.login.oauth2` section is therefore unimplementable in its current form, |
| 25 | +and redundant. It should be removed from the specification to reduce confusion. |
| 26 | + |
| 27 | +## Alternatives |
| 28 | + |
| 29 | +It would be possible to extend the definition so that it is complete: as |
| 30 | +mentioned above, a likely implemenation would be based on OpenID |
| 31 | +Connect. Matrix clients could then follow the standardised OpenID Connect flow |
| 32 | +rather than the matrix-specific `m.login.sso` flow. However, this would require |
| 33 | +significant design work, and development in both clients and servers, which |
| 34 | +currently feels hard to justify when a working solution exists via |
| 35 | +`m.login.sso`. |
0 commit comments