From c69a747bae52296f8a7fe930090c64c98227cd73 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 9 Mar 2020 12:31:06 -0400 Subject: [PATCH 1/8] Convert the initial Google Doc to Markdown. --- proposals/xxxx-ui-interactive-auth-for-sso.md | 262 ++++++++++++++++++ 1 file changed, 262 insertions(+) create mode 100644 proposals/xxxx-ui-interactive-auth-for-sso.md diff --git a/proposals/xxxx-ui-interactive-auth-for-sso.md b/proposals/xxxx-ui-interactive-auth-for-sso.md new file mode 100644 index 00000000..fc7413fe --- /dev/null +++ b/proposals/xxxx-ui-interactive-auth-for-sso.md @@ -0,0 +1,262 @@ +# User-Interactive Auth for SSO-backed homeservers + +## Background + +Certain endpoints, such as `DELETE /_matrix/client/r0/devices/{deviceId}` and +`POST /_matrix/client/r0/account/3pid/add`, require the user to reconfirm their +identity, as a guard against a leaked access token being used to take over an +entire account. + +On a normal homeserver, this is done by prompting the user to enter their +password. However, on a homeserver where users authenticate via a single-sign-on +system, the user doesn't have a password, so this doesn't work. Instead we need +to delegate that check to the SSO system. + +At the protocol level, this means adding support for SSO to +[user-interactive auth](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). + +### The current implementation + +Or, "how UI Auth works, in practice": + +When the client calls one of the protected endpoints, it initially returns a 401 +response. For example: + +``` +POST /_matrix/client/r0/delete_devices HTTP/1.1 +Content-Type: application/json + +{ + "devices": ["FSVVTZRRAA"] +} + +HTTP/1.1 401 Unauthorized +Content-Type: application/json + +{ + "flows": [ + { + "stages": [ + "m.login.password" + ] + } + ], + "params": {}, + "session": "dTKfsLHSAJeAhqfxUsvrIVJd" +} +``` + +The client: + +* inspects the "flows" list +* discovers there is a flow it knows how to follow +* carries out the first "stage" of that flow (m.login.password) + +ie, the client prompts the user to enter a password. + +The client then resubmits with an additional 'auth' param, with "type" giving +the name of the authentication type it has just carried out. That completes the +authentication flow, so the server is now happy, and returns a 200: + +``` +POST /_matrix/client/r0/delete_devices HTTP/1.1 +Content-Type: application/json + +{ + "devices": ["FSVVTZRRAA"], + "auth": { + "session":"dTKfsLHSAJeAhqfxUsvrIVJd", + "type":"m.login.password", + "identifier":{"type":"m.id.user", "user":"@userid:matrix.org"}, + "password":"" + } +} + + +HTTP/1.1 200 OK +Content-Type: application/json +Content-Length: 179 + +{} +``` + +## Proposal + +We add an `m.login.sso` authentication type to the UI auth spec. There are no +additional params as part of this auth type. + +1. If the client wants to complete that authentication type, it opens a browser + window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` + with session set to the UI-Auth session id (from the "auth" dict). + + The homeserver returns a page which says words to the effect of "A client is + trying to remove a device/add an email address/take over your account. To + confirm this action, **re-authenticate with single sign-on**. If you did not + expect this, your account may be compromised!" + + See security section below. +2. The link, once the user clicks on it, goes to the SSO provider's page. +3. The SSO provider validates the user, and redirects the browser back to the + homeserver. +4. The homeserver validates the response from the SSO provider, updates the + user-interactive auth session to show that the SSO has completed, serves the + fallback auth completion page as specced: + https://matrix.org/docs/spec/client_server/r0.6.0#fallback +5. The client resubmits its original request, with its original session id, + which now hopefully completes. + +Note that the post-SSO URL on the homeserver is left up to the homeserver +implementation rather than forming part of the spec. + +* SAML2 servers typically only support one URL per service provider, so in + practice it will need to be the same as that already used for the login flow + (for synapse, it's /_matrix/saml2/authn_response) - and the server needs to + be able to figure out if it's doing SSO for a login attempt or an SSO + attempt. +* CAS doesn't have the same restriction. + +### Example flow: + +0. Client submits the request, which the server says requires SSO: + + ``` + POST /_matrix/client/r0/delete_devices HTTP/1.1 + Content-Type: application/json + Authorization: Bearer xyzzy + + { + "devices": ["FSVVTZRRAA"] + } + + HTTP/1.1 401 Unauthorized + Content-Type: application/json + + { + "flows": [ + { + "stages": [ + "m.login.sso" + ] + } + ], + "params": {}, + "session": "dTKfsLHSAJeAhqfxUsvrIVJd" + } + ``` + +1. Client opens a browser window for the fallback endpoint: + + ``` + GET /_matrix/client/r0/auth/m.login.sso/fallback/web + ?session=dTKfsLHSAJeAhqfxUsvrIVJd HTTP/1.1 + + HTTP/1.1 200 OK + + + can delete device pls? + clicky + + ``` + +2. The user clicks the confirmation link which goes to the SSO provider's site: + + ``` + GET https://sso_provider/validate?SAMLRequest= HTTP/1.1 + + ... SAML/CAS stuff + ``` + +3. The SSO provider validates the user and ends up redirecting the browser back + to the homeserver. (The example below shows a 302 for simplicity but SAML normally uses a 200 with an html
, with javascript to automatically submit it.) + + ``` + HTTP/1.1 302 Moved + Location: https://homeserver/_matrix/saml2/authn_response? + SAMLResponse= + ``` + +4. The browser sends the SSO response to the homeserver, which validates it and + shows the fallback auth completion page: + + ``` + GET /_matrix/saml2/authn_response?SAMLResponse= + + + HTTP/1.1 200 OK + + + +

Thank you.

+

You may now close this window and return to the application.

+ ``` + +5. The client closes the browser popup if it is still open, and resubmits its + original request, which now succeeds: + + ``` + POST /_matrix/client/r0/delete_devices HTTP/1.1 + Content-Type: application/json + Authorization: Bearer xyzzy + + { + "auth": { + "session": "dTKfsLHSAJeAhqfxUsvrIVJd" + } + } + + HTTP/1.1 200 OK + Content-Type: application/json + + {} + ``` + +A few notes: + +* The security of this relies on UI-Auth sessions only being used for the same + request as they were initiated for. I don't think that's currently enforced. +* We might consider an alternative client flow where the fallback auth ends up + redirecting to a given URI, instead of doing javascript postMessage foo. I + think that's an orthogonal change to the fallback auth though. +* In theory, any clients that already implement the fallback process for + unknown authentication types will work fine without modification. + Unfortunately, I don't think Riot (on any platform) is among them. + +## Security considerations + +Recall that the thing we are trying to guard against here is a single leaked +access-token being used to take over an entire account. So let's assume the +attacker has got hold of an access token for your account. What happens if we + skip the confirmation step? + +The attacker, who has your access token, starts a UI-Auth session to add his +email address to your account. + +He then sends you a link "hey, check out this cool video!"; the link leads (via +an innocent-looking url shortener) to +`/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>`, with the ID of +the session that he just created. + +Recall that we're skipping the confirmation step, so the server redirects +straight to the SSO provider. + +It's common for SSO providers to redirect straight back to the app if you've +recently authenticated with them; even in the best case, the SSO provider shows +some innocent message along the lines of "Confirm that you want to sign in to +". + +So the SSO completes, and the attacker's session is validated. + +By telling the user what's about to happen as clearly as we can, and making them +confirm, we can mitigate this problem. + +## Unstable prefix + +We should use a vendor prefix here until this hits the spec. + +`org.matrix.login.sso` ? \ No newline at end of file From f48bbd32788ec8734fbaaa85728197632aeffd61 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 9 Mar 2020 14:00:28 -0400 Subject: [PATCH 2/8] Attempt to clarify the MSC. --- proposals/xxxx-ui-interactive-auth-for-sso.md | 90 ++++++++++--------- 1 file changed, 47 insertions(+), 43 deletions(-) diff --git a/proposals/xxxx-ui-interactive-auth-for-sso.md b/proposals/xxxx-ui-interactive-auth-for-sso.md index fc7413fe..5b6f396d 100644 --- a/proposals/xxxx-ui-interactive-auth-for-sso.md +++ b/proposals/xxxx-ui-interactive-auth-for-sso.md @@ -1,6 +1,4 @@ -# User-Interactive Auth for SSO-backed homeservers - -## Background +# User-Interactive Auth for SSO-backed homeserver Certain endpoints, such as `DELETE /_matrix/client/r0/devices/{deviceId}` and `POST /_matrix/client/r0/account/3pid/add`, require the user to reconfirm their @@ -9,15 +7,17 @@ entire account. On a normal homeserver, this is done by prompting the user to enter their password. However, on a homeserver where users authenticate via a single-sign-on -system, the user doesn't have a password, so this doesn't work. Instead we need -to delegate that check to the SSO system. +system, the user doesn't have a password registered with the homeserver. Instead +we need to delegate that check to the SSO system. At the protocol level, this means adding support for SSO to [user-interactive auth](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). -### The current implementation +In theory, any clients that already implement the fallback process for unknown +authentication types will work fine without modification. It is unknown whether +this is widely supported among clients. -Or, "how UI Auth works, in practice": +### UI Auth Overview When the client calls one of the protected endpoints, it initially returns a 401 response. For example: @@ -52,7 +52,7 @@ The client: * discovers there is a flow it knows how to follow * carries out the first "stage" of that flow (m.login.password) -ie, the client prompts the user to enter a password. +In this example, the client prompts the user to enter a password. The client then resubmits with an additional 'auth' param, with "type" giving the name of the authentication type it has just carried out. That completes the @@ -89,24 +89,25 @@ additional params as part of this auth type. window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` with session set to the UI-Auth session id (from the "auth" dict). - The homeserver returns a page which says words to the effect of "A client is - trying to remove a device/add an email address/take over your account. To - confirm this action, **re-authenticate with single sign-on**. If you did not - expect this, your account may be compromised!" + The homeserver returns a page which asks for the user's confirmation before + proceeding. See the security considerations section below for why this is + necessary. For example, the page could say words to the effect of: - See security section below. + > A client is trying to remove a device/add an email address/take over your + > account. To confirm this action, **re-authenticate with single sign-on**. + > If you did not expect this, your account may be compromised! 2. The link, once the user clicks on it, goes to the SSO provider's page. 3. The SSO provider validates the user, and redirects the browser back to the homeserver. 4. The homeserver validates the response from the SSO provider, updates the - user-interactive auth session to show that the SSO has completed, serves the - fallback auth completion page as specced: - https://matrix.org/docs/spec/client_server/r0.6.0#fallback + user-interactive auth session to show that the SSO has completed, + [serves the fallback auth completion page as specced](https://matrix.org/docs/spec/client_server/r0.6.0#fallback). 5. The client resubmits its original request, with its original session id, - which now hopefully completes. + which now should complete. Note that the post-SSO URL on the homeserver is left up to the homeserver -implementation rather than forming part of the spec. +implementation rather than forming part of the specification, choices might be +limited by the chosen SSO implementation, for example: * SAML2 servers typically only support one URL per service provider, so in practice it will need to be the same as that already used for the login flow @@ -216,47 +217,50 @@ implementation rather than forming part of the spec. {} ``` -A few notes: +## Alternatives -* The security of this relies on UI-Auth sessions only being used for the same - request as they were initiated for. I don't think that's currently enforced. -* We might consider an alternative client flow where the fallback auth ends up - redirecting to a given URI, instead of doing javascript postMessage foo. I - think that's an orthogonal change to the fallback auth though. -* In theory, any clients that already implement the fallback process for - unknown authentication types will work fine without modification. - Unfortunately, I don't think Riot (on any platform) is among them. +An alternative client flow where the fallback auth ends up redirecting to a +given URI, instead of doing JavaScript postMessage foo could be considered. +This is probably an orthogonal change to the fallback auth though. ## Security considerations +### Why we need user to confirm before the SSO flow + Recall that the thing we are trying to guard against here is a single leaked access-token being used to take over an entire account. So let's assume the -attacker has got hold of an access token for your account. What happens if we - skip the confirmation step? +attacker has got hold of an access token for your account. What happens if the +confirmation step is skipped? -The attacker, who has your access token, starts a UI-Auth session to add his -email address to your account. +The attacker, who has your access token, starts a UI Authentication session to +add their email address to your account. -He then sends you a link "hey, check out this cool video!"; the link leads (via -an innocent-looking url shortener) to +They then sends you a link "hey, check out this cool video!"; the link leads (via +an innocent-looking URL shortener or some other phishing technique) to `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>`, with the ID of the session that he just created. -Recall that we're skipping the confirmation step, so the server redirects -straight to the SSO provider. +Since there is no confirmation step, the server redirects directly to the SSO +provider. It's common for SSO providers to redirect straight back to the app if you've recently authenticated with them; even in the best case, the SSO provider shows -some innocent message along the lines of "Confirm that you want to sign in to -". +an innocent message along the lines of "Confirm that you want to sign in to +". -So the SSO completes, and the attacker's session is validated. +After redirecting back to the homeserver, the SSO is completed and the +attacker's session is validated. They are now able to make their malicious +change to your account. -By telling the user what's about to happen as clearly as we can, and making them -confirm, we can mitigate this problem. +This problem can be mitigated by clearly telling the user what is about to happen. + +### Reusing UI-Auth sessions + +The security of this relies on UI-Auth sessions only being used for the same +request as they were initiated for. It is not believed that this is currently +enforced. ## Unstable prefix -We should use a vendor prefix here until this hits the spec. - -`org.matrix.login.sso` ? \ No newline at end of file +A vendor prefix of `org.matrix.login.sso` (instead of `m.login.sso` is proposed +until this is part of the specification. From 4d177753e1e8043b92f9bcec0c4501b9a2802a63 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Mon, 9 Mar 2020 15:05:37 -0400 Subject: [PATCH 3/8] Move proposal to proper proposal number. --- ...active-auth-for-sso.md => 2454-ui-interactive-auth-for-sso.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{xxxx-ui-interactive-auth-for-sso.md => 2454-ui-interactive-auth-for-sso.md} (100%) diff --git a/proposals/xxxx-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md similarity index 100% rename from proposals/xxxx-ui-interactive-auth-for-sso.md rename to proposals/2454-ui-interactive-auth-for-sso.md From 570398e045476fcf4e289367d4856d44b0882b67 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 10 Mar 2020 10:00:58 -0400 Subject: [PATCH 4/8] Remove section on the how the authentication currently works and just reference the specification. --- proposals/2454-ui-interactive-auth-for-sso.md | 65 +------------------ 1 file changed, 1 insertion(+), 64 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index 5b6f396d..bfad25a9 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -11,75 +11,12 @@ system, the user doesn't have a password registered with the homeserver. Instead we need to delegate that check to the SSO system. At the protocol level, this means adding support for SSO to -[user-interactive auth](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). +[user-interactive authentication API](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). In theory, any clients that already implement the fallback process for unknown authentication types will work fine without modification. It is unknown whether this is widely supported among clients. -### UI Auth Overview - -When the client calls one of the protected endpoints, it initially returns a 401 -response. For example: - -``` -POST /_matrix/client/r0/delete_devices HTTP/1.1 -Content-Type: application/json - -{ - "devices": ["FSVVTZRRAA"] -} - -HTTP/1.1 401 Unauthorized -Content-Type: application/json - -{ - "flows": [ - { - "stages": [ - "m.login.password" - ] - } - ], - "params": {}, - "session": "dTKfsLHSAJeAhqfxUsvrIVJd" -} -``` - -The client: - -* inspects the "flows" list -* discovers there is a flow it knows how to follow -* carries out the first "stage" of that flow (m.login.password) - -In this example, the client prompts the user to enter a password. - -The client then resubmits with an additional 'auth' param, with "type" giving -the name of the authentication type it has just carried out. That completes the -authentication flow, so the server is now happy, and returns a 200: - -``` -POST /_matrix/client/r0/delete_devices HTTP/1.1 -Content-Type: application/json - -{ - "devices": ["FSVVTZRRAA"], - "auth": { - "session":"dTKfsLHSAJeAhqfxUsvrIVJd", - "type":"m.login.password", - "identifier":{"type":"m.id.user", "user":"@userid:matrix.org"}, - "password":"" - } -} - - -HTTP/1.1 200 OK -Content-Type: application/json -Content-Length: 179 - -{} -``` - ## Proposal We add an `m.login.sso` authentication type to the UI auth spec. There are no From 78e08c1987460cd14eba27f503b95b6dc4083a29 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Tue, 10 Mar 2020 10:11:08 -0400 Subject: [PATCH 5/8] Attempt to clarify the proposed changes. --- proposals/2454-ui-interactive-auth-for-sso.md | 38 +++++++++++-------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index bfad25a9..d3cab51b 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -1,4 +1,4 @@ -# User-Interactive Auth for SSO-backed homeserver +# User-Interactive Authentication for SSO-backed homeserver Certain endpoints, such as `DELETE /_matrix/client/r0/devices/{deviceId}` and `POST /_matrix/client/r0/account/3pid/add`, require the user to reconfirm their @@ -10,17 +10,21 @@ password. However, on a homeserver where users authenticate via a single-sign-on system, the user doesn't have a password registered with the homeserver. Instead we need to delegate that check to the SSO system. -At the protocol level, this means adding support for SSO to +At the protocol level, this means adding support for SSO to the [user-interactive authentication API](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). -In theory, any clients that already implement the fallback process for unknown -authentication types will work fine without modification. It is unknown whether -this is widely supported among clients. +In theory, once SSO is added as a possible flow for authentication any clients +that already implement the [fallback process for unknown authentication types](https://matrix.org/docs/spec/client_server/r0.6.0#fallback) +will work fine without modification. It is unknown whether this is widely +supported among clients. ## Proposal -We add an `m.login.sso` authentication type to the UI auth spec. There are no -additional params as part of this auth type. +An [additional authentication type](https://matrix.org/docs/spec/client_server/r0.6.0#authentication-types) +of `m.login.sso` is added to the user-interactive authentication specification. +There are no additional parameters as part of this authentication type. + +When choosing this authentication flow, the following should occur: 1. If the client wants to complete that authentication type, it opens a browser window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` @@ -91,8 +95,9 @@ limited by the chosen SSO implementation, for example: HTTP/1.1 200 OK - can delete device pls? - clicky + A client is trying to remove a device from your account. To confirm this + action, re-authenticate with single sign-on. + If you did not expect this, your account may be compromised! ``` @@ -101,11 +106,12 @@ limited by the chosen SSO implementation, for example: ``` GET https://sso_provider/validate?SAMLRequest= HTTP/1.1 - ... SAML/CAS stuff + ``` 3. The SSO provider validates the user and ends up redirecting the browser back - to the homeserver. (The example below shows a 302 for simplicity but SAML normally uses a 200 with an html , with javascript to automatically submit it.) + to the homeserver. The example below shows a 302 for simplicity, this might + vary based on SSO implementation. ``` HTTP/1.1 302 Moved @@ -191,13 +197,13 @@ change to your account. This problem can be mitigated by clearly telling the user what is about to happen. -### Reusing UI-Auth sessions +### Reusing User Interactive Authentication sessions -The security of this relies on UI-Auth sessions only being used for the same -request as they were initiated for. It is not believed that this is currently -enforced. +The security of this relies on User Interactive Authentication sessions only +being used for the same request as they were initiated for. It is not believed +that this is currently enforced. ## Unstable prefix -A vendor prefix of `org.matrix.login.sso` (instead of `m.login.sso` is proposed +A vendor prefix of `org.matrix.login.sso` is proposed (instead of `m.login.sso`) until this is part of the specification. From eb48863c4044105b86d62997d88a086eda22e690 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Thu, 26 Mar 2020 11:47:32 -0400 Subject: [PATCH 6/8] Markdown formatting. Co-Authored-By: Hubert Chathi --- proposals/2454-ui-interactive-auth-for-sso.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index d3cab51b..3532a2fc 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -52,7 +52,7 @@ limited by the chosen SSO implementation, for example: * SAML2 servers typically only support one URL per service provider, so in practice it will need to be the same as that already used for the login flow - (for synapse, it's /_matrix/saml2/authn_response) - and the server needs to + (for synapse, it's `/_matrix/saml2/authn_response`) - and the server needs to be able to figure out if it's doing SSO for a login attempt or an SSO attempt. * CAS doesn't have the same restriction. From 4cfcda57fb3676d6de6145bb9bd1f9de60645559 Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 1 Apr 2020 10:48:05 -0400 Subject: [PATCH 7/8] Clarify that the only new item here is the new authentication type. --- proposals/2454-ui-interactive-auth-for-sso.md | 31 ++++++++++++++++--- 1 file changed, 26 insertions(+), 5 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index 3532a2fc..fff96dcf 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -22,11 +22,27 @@ supported among clients. An [additional authentication type](https://matrix.org/docs/spec/client_server/r0.6.0#authentication-types) of `m.login.sso` is added to the user-interactive authentication specification. -There are no additional parameters as part of this authentication type. + +There are no additional parameters as part of this authentication type. As per +the user-interactive authentication specification the only parameter include in +the `auth` dictionary should be the session ID from the homeserver, e.g.: + +```json +{ + "auth": { + "session": "" + } +} +``` + +### Detailed fallback authentication flow: + +The following is a re-iteration of the [fallback authentication flow](https://matrix.org/docs/spec/client_server/r0.6.0#fallback), +but with details filled in for the proposed new authentication type. When choosing this authentication flow, the following should occur: -1. If the client wants to complete that authentication type, it opens a browser +1. If the client wants to complete authentication using SSO, it opens a browser window for `/_matrix/client/r0/auth/m.login.sso/fallback/web?session=<...>` with session set to the UI-Auth session id (from the "auth" dict). @@ -59,6 +75,10 @@ limited by the chosen SSO implementation, for example: ### Example flow: +A more complete example is provided below in which a user attempts to delete +a device and is pushed into the user interactive authentication process with +SSO being the only possible flow. + 0. Client submits the request, which the server says requires SSO: ``` @@ -163,7 +183,7 @@ limited by the chosen SSO implementation, for example: ## Alternatives An alternative client flow where the fallback auth ends up redirecting to a -given URI, instead of doing JavaScript postMessage foo could be considered. +given URI, instead of doing JavaScript `postMessage` foo could be considered. This is probably an orthogonal change to the fallback auth though. ## Security considerations @@ -200,8 +220,9 @@ This problem can be mitigated by clearly telling the user what is about to happe ### Reusing User Interactive Authentication sessions The security of this relies on User Interactive Authentication sessions only -being used for the same request as they were initiated for. It is not believed -that this is currently enforced. +being used for the same request as they were initiated for. This security is not +only a concern for the proposed SSO authentication type. It is not believed +that this is currently enforced in implementations. ## Unstable prefix From f6879c897bace91ccfe0cb102f490e9dc5619cde Mon Sep 17 00:00:00 2001 From: Patrick Cloke Date: Wed, 15 Apr 2020 07:39:00 -0400 Subject: [PATCH 8/8] Fix minor grammatical fixes. Co-Authored-By: Hubert Chathi --- proposals/2454-ui-interactive-auth-for-sso.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2454-ui-interactive-auth-for-sso.md b/proposals/2454-ui-interactive-auth-for-sso.md index fff96dcf..e39facfb 100644 --- a/proposals/2454-ui-interactive-auth-for-sso.md +++ b/proposals/2454-ui-interactive-auth-for-sso.md @@ -13,7 +13,7 @@ we need to delegate that check to the SSO system. At the protocol level, this means adding support for SSO to the [user-interactive authentication API](https://matrix.org/docs/spec/client_server/r0.6.0#user-interactive-authentication-api). -In theory, once SSO is added as a possible flow for authentication any clients +In theory, once SSO is added as a possible flow for authentication, any clients that already implement the [fallback process for unknown authentication types](https://matrix.org/docs/spec/client_server/r0.6.0#fallback) will work fine without modification. It is unknown whether this is widely supported among clients. @@ -24,7 +24,7 @@ An [additional authentication type](https://matrix.org/docs/spec/client_server/r of `m.login.sso` is added to the user-interactive authentication specification. There are no additional parameters as part of this authentication type. As per -the user-interactive authentication specification the only parameter include in +the user-interactive authentication specification, the only parameter included in the `auth` dictionary should be the session ID from the homeserver, e.g.: ```json @@ -57,7 +57,7 @@ When choosing this authentication flow, the following should occur: 3. The SSO provider validates the user, and redirects the browser back to the homeserver. 4. The homeserver validates the response from the SSO provider, updates the - user-interactive auth session to show that the SSO has completed, + user-interactive auth session to show that the SSO has completed, and [serves the fallback auth completion page as specced](https://matrix.org/docs/spec/client_server/r0.6.0#fallback). 5. The client resubmits its original request, with its original session id, which now should complete.