Merge pull request #2858 from matrix-org/t3chguy/msc/multi-sso

MSC2858: Multiple SSO Identity Providers

Author: turt2live

proposals/2858-Multiple-SSO-Identity-Providers.md

@@ -0,0 +1,247 @@
+# MSC2858: Multiple SSO Identity Providers
+
+Matrix already has generic SSO support, but it does not yield the best user experience especially for
+instances which wish to offer multiple identity providers (IdPs). This MSC provides a simple and fully
+backwards compatible way to extend the current spec which would allow clients to give users options
+like `Continue with Google` and `Continue with Github` side-by-side.
+
+Currently, Matrix supports `m.login.sso`, `m.login.token` and `/login/sso/redirect` for clients to
+pass their user to the configured Identity provider and for them to come back with something which
+is exchangeable for a Matrix access token. This flow offers no insight to the user as to what
+Identity providers are available: clients can offer only a very generic `Sign in with SSO`
+button. With the currently possible solutions and workarounds the experience is far from great
+and users have to blindly click `Sign in with SSO` without any clue as to what's hiding on the other
+side of the door. Some users will definitely not be familiar with `SSO` but will be with the concept of
+"Continue with Google" or similar.
+
+## Proposal
+
+We extend the [login
+flow](https://matrix.org/docs/spec/client_server/r0.6.1#login) to allow clients
+to choose an SSO Identity provider before control is handed over to the
+server. The following sequence diagram illustrates the proposed, updated, login flow:
+
+<!-- source for the following is in images/2858-seq-diagram.txt -->
+
+![Sequence diagram](https://user-images.githubusercontent.com/2403652/104897523-61fb4b00-5970-11eb-88f7-9fc0956b33a2.png)
+
+### Extensions to login flow discovery
+
+The response to [`GET /_matrix/client/r0/login`](https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-login)
+is extended to **optionally** include an `identity_providers` property for
+flows whose type `m.login.sso`. This would look like this:
+
+```json
+{
+    "flows": [
+        {
+            "type": "m.login.sso",
+            "identity_providers": [
+                {
+                    "id": "google",
+                    "name": "Google",
+                    "icon": "mxc://...",
+                    "brand": "google"
+                },
+                {
+                    "id": "github",
+                    "name": "Github",
+                    "icon": "mxc://...",
+                    "brand": "github"
+                }
+            ]
+        },
+        {
+            "type": "m.login.token"
+        }
+    ]
+}
+```
+
+The value of the `identity_providers` property is a list, each entry consisting
+of an object with the following fields:
+
+ * The `id` field is **required**. It is an opaque string chosen by the
+   homeserver implementation, and uniquely identifies the identity provider on
+   that server. Clients should not infer any semantic meaning from the
+   identifier. The identifier should be between 1 and 255 characters in length,
+   and should consist of the characters matching unreserved URI characters as
+   defined in [RFC3986](http://www.ietf.org/rfc/rfc3986.txt):
+
+   ```
+   ALPHA  DIGIT  "-" / "." / "_" / "~"
+   ```
+
+ * The `name` field is **required**. It should be a human readable string
+   intended for printing by the client. No explicit length limit or grammar is
+   specified.
+
+ * The `icon` field is **optional**. It should point to an icon representing
+   the IdP. If present then it must be an MXC URI to an image resource.
+
+ * The `brand` field is **optional**. It allows the client to style the login
+   button to suit a particular brand. It should be a string using the following
+   grammar:
+
+    * Must be at least one character and no more than 255 characters in length.
+    * Must start with one of the characters `[a-z]`, and be entirely composed
+      of the characters `[a-z]`, `[0-9]`, `-`, `_` and `.`.
+
+   To reduce confusion over which identifier should be used for each brand
+   (for example: should "Sign in with Microsoft" be `microsoft` or
+   `azure`?), it is proposed to maintain a registry of identifiers outside
+   the core specification document, avoiding the need for a full MSC to add
+   entries to the list. An initial list of proposed identifiers is given below.
+
+   [Rationale: this grammar is based on the
+   [MSC2758](https://github.com/matrix-org/matrix-doc/pull/2758), removing the
+   requirements for a namespaced heirarchy. In
+   [discussion](https://github.com/matrix-org/matrix-doc/pull/2858#discussion_r565506802),
+   it was agreed that a separate registry was seen as important for a
+   lightweight process by which implementations can agree on identifiers. The
+   registry makes the namespacing of MSC2758 redundant; the namespacing system
+   was also somewhat confusing.]
+
+   Server implementations are free to add additional brands, though they should
+   be mindful of clients which do not recognise any given brand.
+
+   Clients are free to implement any set of brands they wish, including all or
+   any of the brands listed in the registry, but are expected to apply a
+   sensible unbranded fallback for any brand they do not recognise/support.
+
+   Where `icon` and `brand` are both present, it is recommended that clients
+   which support the `brand` give precedence to `brand` over `icon`.
+
+### Extend the `/login/sso/redirect` endpoint
+
+A new endpoint is added to support redirecting directly to one of the IdPs:
+
+`GET /_matrix/client/r0/login/sso/redirect/{idp_id}`
+
+This would behave identically to the existing endpoint without the last argument
+except would allow the server to forward the user directly to the correct IdP.
+
+For the case of backwards compatibility the existing endpoint is to remain,
+and if the server supports multiple SSO IdPs it should offer the user a page
+which lets them choose between the available IdP options as a fallback.
+
+If the `idp_id` is unrecognised, the server should display some sort of error
+page to the user. (A protocol whereby an error can be returned to the original
+client could be a matter for a future improvement, but is out of scope for now.)
+
+### Notes on user-interactive auth
+
+No change is proposed to the SSO flow for User-Interactive Authentication.
+
+For a reauthentication operation, the server implementation is free to choose
+any suitable IdP to authenticate the user. (Often, this will simply be
+the IdP that the user logged in with.)
+
+### Proposed initial identifiers for the `brand` indentifier
+
+The following identifiers are proposed for the initial content of the `brand`
+identifier registry. The descriptions are guidelines to help server
+administrators pick a suitable brand identifier, and to help client authors
+style buttons in their clients.
+
+ * Identifier: `apple`
+
+   Description: Suitable for "Sign in with Apple": see
+   https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/.
+
+ * Identifier: `facebook`
+
+   Description: "Continue with Facebook": see
+   https://developers.facebook.com/docs/facebook-login/web/login-button/.
+
+ * Identifier: `github`
+
+   Description: Logos available at https://github.com/logos.
+
+ * Identifier: `gitlab`
+
+   Description: Logos available at https://about.gitlab.com/press/press-kit/.
+
+ * Identifier: `google`
+
+   Description: Suitable for "Google Sign-In": see
+   https://developers.google.com/identity/branding-guidelines.
+
+ * Identifier: `twitter`
+
+   Description: Suitable for "Log in with Twitter": see
+   https://developer.twitter.com/en/docs/authentication/guides/log-in-with-twitter#tab1.
+
+When considering a new identifier for private use, administrators should pick
+some sensible name following the advice of [RFC6648 sec
+3](https://tools.ietf.org/html/rfc6648#section-3).
+
+## Alternatives
+
+An alternative to the whole approach would be to allow `m.login.sso.$idp` but this forces
+treating an opaque identifier as hierarchical and offers worse backwards compatibility.
+
+An alternative to the proposed backwards compatibility plan where the server offers a
+fallback page which fills the gap and lets the user choose which SSO IdP they need is
+for the server to deterministically always pick one, maybe the first option and let
+old clients only auth via that one but that means potentially locking users out of their
+accounts.
+
+[MSC2964](https://github.com/matrix-org/matrix-doc/pull/2964) proposes
+replacing much of Matrix's authentication mechanism with OAuth2.0. If that is
+adopted, then the Matrix client would not be able to specify an authentication
+mechanism; rather it is left up to the server to host pages allowing the user
+to choose their authentication mechanism.
+
+### Styling information as an alternative to `brand`
+
+The `brand` field is intended to allow clients to style "login" buttons according
+to the identity provider in question. For example, a mobile application might
+show:
+
+![login buttons](images/2858-login.png)
+
+Some identity providers have very specific rules about how such buttons should
+be presented, so a fine level of control is important.
+
+An alternative way to achieve this would be for the server to give full details
+about the styling: icon, font colour, border colour, background colour,
+etc. However, this soon becomes unscalable. For example, it might be desirable
+to offer each logo at a range of resolutions to suit different screen sizes.
+Likewise, some brands need different styling depending on the background
+colour, so a complete second set of colours must be specified to account for
+dark or light themes.
+
+## Potential issues
+
+ * New Identity Providers added by server administators will be unbranded until
+   clients adopt support for the new brand.
+
+## Security considerations
+
+This could potentially aid phishing attacks by bad homeservers, where if the app says
+`Continue with Google` and then they are taken to a page which is styled to look like
+the Google login page they might be a tiny bit more susceptible to being phished as opposed
+as to when they click a more generic `Sign in with SSO` button, but this attack was possible
+anyhow using a different vector of a controlled Element/client instance which modifies
+the text.
+
+
+## Unstable prefix
+
+Whilst in development use `org.matrix.msc2858.identity_providers` for the flow
+discovery and
+`/_matrix/client/unstable/org.matrix.msc2858/login/sso/redirect/{idp_id}` for
+the new endpoints.
+
+When identity providers are listed under the experimental
+`org.matrix.msc2858.identity_providers` field of the response to `/login`,
+(instead of `identity_providers`), different values for the `brand` field are
+used. In particular the following were defined:
+
+  * `org.matrix.gitlab` (now `gitlab`).
+  * `org.matrix.github` (now `github`).
+  * `org.matrix.apple` (now `apple`).
+  * `org.matrix.google` (now `google`).
+  * `org.matrix.facebook` (now `facebook`).
+  * `org.matrix.twitter` (now `twitter`).