Clarifications to SSO login/UIA #2608

richvdh · 2020-06-04T21:53:57Z

including a bunch of text about security.

including a bunch of text about security

turt2live

Generally lgtm - just some questions and minor clarifications

specification/client_server_api.rst

turt2live · 2020-06-05T15:37:30Z

specification/modules/sso_login.rst

+
+An overview of the process is as follows:
+
+0. The Matrix client calls |GET /login|_ to find the supported login


Please can we start numbered lists at one?

we can, though in this case step zero felt very much like a preliminary step.

It's just a bit awkward to have things start at zero, as it implies that it's not a real step (at least imo).

that implication is correct, imo :)

specification/modules/sso_login.rst

turt2live · 2020-06-05T15:46:21Z

specification/modules/sso_login.rst

-<../index.html#mapping-from-other-character-sets>`_ may be useful.
+   This confirmation could take place before redirecting to the SSO
+   authentication page (when handling the
+   ``/_matrix/client/%CLIENT_MAJOR_VERSION%/auth/m.login.sso/fallback/web``


fwiw we have a history of shortening URLs to after the version (ie: /auth/m.login.sso/fallback/web), largely for legibility.

mmhmm. There was some inconsistency here and I went this way: do you think I should go the other?

I don't personally have a preference, just mentioning it in the event it felt annoying to have to do it every time.

specification/modules/sso_login.rst

Co-authored-by: Travis Ralston <travpc@gmail.com>

turt2live

Thanks!

KitsuneRal · 2020-06-05T11:55:10Z

specification/modules/sso_login.rst

+1. To initiate the ``m.login.sso`` login type, the Matrix client instructs the
+   user's browser to navigate to the |/login/sso/redirect|_ endpoint on the
+   user's homeserver.


I know it's taken from the current text but it's a bit too specific, in my opinion. It's not really necessary to assume that SSO requires a web view which is generally, but not necessarily the case. The flow between (1) and (4) only requires HTTP(S). (3) doesn't need even that: interaction with the Auth server can be driven by API (voice authentication through a SIP call; local agent providing SSO; you name it). The wording here also implies that the user's browser is somewhat separate from the client while the text later suggests using an embedded web view for native applications.

Suggested change

1. To initiate the ``m.login.sso`` login type, the Matrix client instructs the

user's browser to navigate to the |/login/sso/redirect|_ endpoint on the

user's homeserver.

1. To initiate the ``m.login.sso`` login type, the Matrix client dispatches

a call to the |/login/sso/redirect|_ endpoint on the user's homeserver.

Depending on the client architecture, the call and further flow can

either be performed by the client itself or the client may use a suitable

embedded view or external application (e.g. a web browser if the flow is

web-based). This client-side party of the authentication process (the Matrix

client itself or the view/application) is further referred to as

"authenticating agent".

Further proposed changes below.

KitsuneRal · 2020-06-05T11:56:54Z

specification/modules/sso_login.rst

+
+1. To initiate the ``m.login.sso`` login type, the Matrix client instructs the
+   user's browser to navigate to the |/login/sso/redirect|_ endpoint on the
+   user's homeserver.

 2. The homeserver responds with an HTTP redirect to the SSO user interface,
   which the browser follows.


Suggested change

which the browser follows.

which the authenticating agent follows.

KitsuneRal · 2020-06-05T12:08:36Z

specification/modules/sso_login.rst

+3. The authentication server and the homeserver interact to verify the user's
+   identity and other authentication information, potentially using a number of
+   redirects.


Surely there was a typo? Interaction is not with the homeserver at this stage.

Suggested change

3. The authentication server and the homeserver interact to verify the user's

identity and other authentication information, potentially using a number of

redirects.

3. The authentication server and the authenticating agent interact

to verify the user's identity and other authentication information,

potentially using a number of redirects.

KitsuneRal · 2020-06-05T13:12:08Z

specification/modules/sso_login.rst

+4. The browser is directed to the ``redirectUrl`` provided by the client with
   a ``loginToken`` query parameter for the client to log in with.


Suggested change

4. The browser is directed to the ``redirectUrl`` provided by the client with

a ``loginToken`` query parameter for the client to log in with.

4. Upon successful completion of (3) the authentication server directs

the authenticating agent to the ``redirectUrl`` provided by the client at step (1),

adding a ``loginToken`` query parameter for the client to log in with.

KitsuneRal · 2020-06-05T13:14:52Z

specification/modules/sso_login.rst

+For native applications, typically steps 1 to 4 are carried out by opening an
+embedded web view.


Suggested change

For native applications, typically steps 1 to 4 are carried out by opening an

embedded web view.

For native applications and web-based authentication flows, typically

steps 1 to 4 are carried out by opening an embedded web view.

KitsuneRal · 2020-06-05T13:27:15Z

specification/modules/sso_login.rst

+
+   Instead, the state could be stored in `localStorage
+   <https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage>`_ or
+   in a cookie.


Suggested change

in a cookie.

in a cookie; native clients should also keep state local to them.

KitsuneRal · 2020-06-05T13:50:11Z

specification/modules/sso_login.rst

-and the REST endpoints which consume the ticket. A good reference for how CAS could
-be implemented is available in the older `r0.4.0 version <https://matrix.org/docs/spec/client_server/r0.4.0.html#cas-based-client-login>`_
-of this specification.
+The server should handle


Just for the sake of clarity

Suggested change

The server should handle

The homeserver should handle

KitsuneRal · 2020-06-05T16:17:22Z

specification/modules/sso_login.rst

+      |      |                                |                   |
+      |      |<========(3) Authentication process================>|
+      |      |                                |                   |
+      |      |<--(4) redirect to redirectUrl--|                   |


If it's really the homeserver invoking the redirect then how does it figure out that the auth flow has been successful? The sequence has a gap between 3 and 4.

KitsuneRal · 2020-06-05T17:15:22Z

specification/modules/sso_login.rst

+#. The homeserver should generate a short-term login token. This is an opaque
+   token, suitable for use with the ``m.login.token`` type of the |/login|_
+   API. The lifetime of this token SHOULD be limited to around five
+   seconds.


This seems to assume relatively quick roundtrip between the client and the homeserver?

KitsuneRal · 2020-06-05T17:19:38Z

specification/modules/sso_login.rst

+   parameters. If it already includes one or more ``loginToken`` parameters,
+   they should be removed before adding the new one.)
+
+#. The homeserver redirects the user's browser to the URI thus built.


Suggested change

#. The homeserver redirects the user's browser to the URI thus built.

#. The homeserver redirects the client to the URI thus built.

Clarifications to SSO login/UIA

57e9e54

including a bunch of text about security

richvdh requested a review from a team June 4, 2020 21:54

add missing anchor

5f8fa53

turt2live reviewed Jun 5, 2020

View reviewed changes

richvdh commented Jun 5, 2020

View reviewed changes

specification/modules/sso_login.rst Outdated Show resolved Hide resolved

Apply suggestions from code review

2d26e1a

Co-authored-by: Travis Ralston <travpc@gmail.com>

richvdh requested a review from turt2live June 5, 2020 15:56

turt2live approved these changes Jun 5, 2020

View reviewed changes

richvdh merged commit da740bf into master Jun 5, 2020

KitsuneRal requested changes Jun 5, 2020

View reviewed changes

afranke deleted the rav/clarify_openid branch September 22, 2021 10:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarifications to SSO login/UIA #2608

Clarifications to SSO login/UIA #2608

richvdh commented Jun 4, 2020

turt2live left a comment

turt2live Jun 5, 2020

richvdh Jun 5, 2020

turt2live Jun 5, 2020

richvdh Jun 5, 2020

turt2live Jun 5, 2020

richvdh Jun 5, 2020

turt2live Jun 5, 2020

turt2live left a comment

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020

KitsuneRal Jun 5, 2020


		An overview of the process is as follows:

		0. The Matrix client calls \|GET /login\|_ to find the supported login

-. To initiate the ``m.login.sso`` login type, the Matrix client instructs the
-   user's browser to navigate to the |/login/sso/redirect|_ endpoint on the
-   user's homeserver.
+. To initiate the ``m.login.sso`` login type, the Matrix client dispatches
+   a call to the |/login/sso/redirect|_ endpoint on the user's homeserver.
+   Depending on the client architecture, the call and further flow can
+   either be performed by the client itself or the client may use a suitable
+   embedded view or external application (e.g. a web browser if the flow is
+   web-based). This client-side party of the authentication process (the Matrix
+   client itself or the view/application) is further referred to as
+   "authenticating agent".

	which the browser follows.
	which the authenticating agent follows.

		4. The browser is directed to the ``redirectUrl`` provided by the client with
		a ``loginToken`` query parameter for the client to log in with.

-. The browser is directed to the ``redirectUrl`` provided by the client with
-   a ``loginToken`` query parameter for the client to log in with.
+. Upon successful completion of (3) the authentication server directs
+   the authenticating agent to the ``redirectUrl`` provided by the client at step (1),
+   adding a ``loginToken`` query parameter for the client to log in with.

		For native applications, typically steps 1 to 4 are carried out by opening an
		embedded web view.

	in a cookie.
	in a cookie; native clients should also keep state local to them.

	#. The homeserver redirects the user's browser to the URI thus built.
	#. The homeserver redirects the client to the URI thus built.

Clarifications to SSO login/UIA #2608

Clarifications to SSO login/UIA #2608

Conversation

richvdh commented Jun 4, 2020

turt2live left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

turt2live left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment