From 7549b86192600d085b35dc0b145c2511e0616167 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Fri, 5 Jun 2020 10:15:55 +0100 Subject: [PATCH 1/2] Proposal to remove `m.login.oauth2` --- proposals/2610-remove-oauth2-auth-type.md | 35 +++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 proposals/2610-remove-oauth2-auth-type.md diff --git a/proposals/2610-remove-oauth2-auth-type.md b/proposals/2610-remove-oauth2-auth-type.md new file mode 100644 index 00000000..e2437a48 --- /dev/null +++ b/proposals/2610-remove-oauth2-auth-type.md @@ -0,0 +1,35 @@ +# MSC2610: Remove `m.login.oauth2` User-Interactive Authentication type from the specification + +The client-server API specification +[defines](https://matrix.org/docs/spec/client_server/r0.6.1#authentication-types) +a number of "authentication types" for use with the User-Interactive +Authentication protocol. + +Of these, `m.login.oauth2` is underspecified and of no +real use. This MSC proposes removing them. + +## Proposal + +The definition of +[OAuth2-based](https://matrix.org/docs/spec/client_server/r0.6.1#oauth2-based) +authentication is incomplete. [OAuth2](https://oauth.net/2/) is best considered +as a framework for implementing authentication protocols rather than a protocol +in its own right, and this section says nothing about the grant types, flows +and scopes which a compliant implemenation should understand. + +A better candidate for OAuth2-based authentication of matrix clients is via +[OpenID Connect](https://openid.net/connect/), but this has already been +implemented in Matrix via the `m.login.sso` authentication type. + +The `m.login.oauth2` section is therefore unimplementable in its current form, +and redundant. It should be removed from the specification to reduce confusion. + +## Alternatives + +It would be possible to extend the definition so that it is complete: as +mentioned above, a likely implemenation would be based on OpenID +Connect. Matrix clients could then follow the standardised OpenID Connect flow +rather than the matrix-specific `m.login.sso` flow. However, this would require +significant design work, and development in both clients and servers, which +currently feels hard to justify when a working solution exists via +`m.login.sso`. From ac982410b94f749e8ad87d7cfc548f17fc221a43 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Date: Thu, 11 Jun 2020 11:18:29 +0100 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/2610-remove-oauth2-auth-type.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2610-remove-oauth2-auth-type.md b/proposals/2610-remove-oauth2-auth-type.md index e2437a48..05b5677c 100644 --- a/proposals/2610-remove-oauth2-auth-type.md +++ b/proposals/2610-remove-oauth2-auth-type.md @@ -15,7 +15,7 @@ The definition of authentication is incomplete. [OAuth2](https://oauth.net/2/) is best considered as a framework for implementing authentication protocols rather than a protocol in its own right, and this section says nothing about the grant types, flows -and scopes which a compliant implemenation should understand. +and scopes which a compliant implementation should understand. A better candidate for OAuth2-based authentication of matrix clients is via [OpenID Connect](https://openid.net/connect/), but this has already been @@ -27,7 +27,7 @@ and redundant. It should be removed from the specification to reduce confusion. ## Alternatives It would be possible to extend the definition so that it is complete: as -mentioned above, a likely implemenation would be based on OpenID +mentioned above, a likely implementation would be based on OpenID Connect. Matrix clients could then follow the standardised OpenID Connect flow rather than the matrix-specific `m.login.sso` flow. However, this would require significant design work, and development in both clients and servers, which