From 79c74c29270d8dcd54a530d0d1470e07bc9cb954 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Thu, 3 Jun 2021 20:43:54 +0100 Subject: [PATCH 01/15] Proposal for token authenticated registration Signed-off-by: Callum Brown --- .../3231-token-authenticated-registration.md | 66 +++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 proposals/3231-token-authenticated-registration.md diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md new file mode 100644 index 00000000000..6cda44d53cc --- /dev/null +++ b/proposals/3231-token-authenticated-registration.md @@ -0,0 +1,66 @@ +# MSC3231: Token Authenticated Registration + +Currently, homeserver administrators must choose between allowing anyone to register and completely disabling registrations. This is a problem for administrators who want to let certain people have an account on their server, but do not want to register the accounts manually (possibly because the initial password may not be changed by the user). + +There are some existing external solutions (see the **Alternatives** section), but these require additional effort from administrators and are disconnected from Matrix clients. It would be useful for administrators to have a convenient method of limiting registrations to certain people which requires minimal setup and is integrated with existing clients. + +## Proposal + +The [/\_matrix/client/r0/register](https://spec.matrix.org/unstable/client-server-api/#post_matrixclientr0register) endpoint uses the [User-Interactive Authentication API](https://spec.matrix.org/unstable/client-server-api/#user-interactive-authentication-api). A new authentication type `m.registration.token` will be defined which requires a `token` key to be present in the submitted `auth` dict. The token will be a string which the homeserver can match against its records to authenticate the registration request. + +For example, when a client attempts registration with no `auth` dict, a server may respond with: + +``` +HTTP/1.1 401 Unauthorized + +{ + "flows": [ + { + "stages": [ "m.registration.token" ] + } + ], + "params": {}, + "session": "xxxxx" +} +``` + +The client would then prompt the user to enter a token and send a new request with an `auth` dict: + +``` +POST /_matrix/client/r0/register + +{ + "auth": { + "type": "m.registration.token", + "token": "fBVFdqVE", + "session": "xxxxx" + } + "device_id": "ABC", + "initial_device_display_name": "Some Client", + "password": "badpassword", + "username": "bob" +} +``` + +If the server verifies that `fBVFdqVE` is a valid token then the account is registered as normal, otherwise a `401` status is returned. On the successful use of a token the server may alter the validity of the token. For example, the token may be completely invalidated, or its number of permitted uses reduced. Management of the tokens is left to the server implementation. + +Using the User-Interactive Authentication API means clients' existing registration logic will be unaffected, with a fallback available for clients without native support for the new authentication type. + + +## Potential issues + +The new authentication type would only apply to the `/_matrix/client/r0/register` endpoint. This should not cause problems, but it would be worth noting in any change to the specification. + + +## Alternatives + +[matrix-registration](https://github.com/ZerataX/matrix-registration/) is an application which provides token management and a standalone web interface. It uses Synapse's admin API to do registrations. + +[Midnight](https://github.com/KombuchaPrivacy/midnight) sits in front of a homeserver and handles the `/_matrix/client/r0/register` endpoint. It provides token management and does additional checks on the requested username. Registration requests are forwarded to the homeserver once authenticated. It uses the User-Interactive Authentication API in a very similar way to this MSC, which could allow existing Matrix clients to be used. + +[matrix-register-bot](https://github.com/krombel/matrix-register-bot) is a Matrix bot which allows registrations done through the provided web interface to be accepted or denied by users in a certain room. When a registration is approved temporary credentials are sent to the user's verified email address. It can use Synapse's admin API or [matrix-synapse-rest-auth](https://github.com/kamax-matrix/matrix-synapse-rest-password-provider#integrate) to do the registration. + + +## Unstable prefix + +Implementations should use `org.matrix.msc3231.registration.token` as the authentication type until this MSC is part of a released version of the specification. From 0a93e43f30caabdac2306b067f07058c94fea4a8 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Fri, 4 Jun 2021 15:32:25 +0100 Subject: [PATCH 02/15] Hard-wrap lines Signed-off-by: Callum Brown --- .../3231-token-authenticated-registration.md | 63 +++++++++++++++---- 1 file changed, 50 insertions(+), 13 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 6cda44d53cc..901f166a8c6 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -1,14 +1,28 @@ # MSC3231: Token Authenticated Registration -Currently, homeserver administrators must choose between allowing anyone to register and completely disabling registrations. This is a problem for administrators who want to let certain people have an account on their server, but do not want to register the accounts manually (possibly because the initial password may not be changed by the user). - -There are some existing external solutions (see the **Alternatives** section), but these require additional effort from administrators and are disconnected from Matrix clients. It would be useful for administrators to have a convenient method of limiting registrations to certain people which requires minimal setup and is integrated with existing clients. +Currently, homeserver administrators must choose between allowing anyone to +register and completely disabling registrations. This is a problem for +administrators who want to let certain people have an account on their server, +but do not want to register the accounts manually (possibly because the +initial password may not be changed by the user). + +There are some existing external solutions (see the **Alternatives** section), +but these require additional effort from administrators and are disconnected +from Matrix clients. It would be useful for administrators to have a convenient +method of limiting registrations to certain people which requires minimal setup +and is integrated with existing clients. ## Proposal -The [/\_matrix/client/r0/register](https://spec.matrix.org/unstable/client-server-api/#post_matrixclientr0register) endpoint uses the [User-Interactive Authentication API](https://spec.matrix.org/unstable/client-server-api/#user-interactive-authentication-api). A new authentication type `m.registration.token` will be defined which requires a `token` key to be present in the submitted `auth` dict. The token will be a string which the homeserver can match against its records to authenticate the registration request. +The [/\_matrix/client/r0/register](https://spec.matrix.org/unstable/client-server-api/#post_matrixclientr0register) +endpoint uses the [User-Interactive Authentication API](https://spec.matrix.org/unstable/client-server-api/#user-interactive-authentication-api). +A new authentication type `m.registration.token` will be defined which requires +a `token` key to be present in the submitted `auth` dict. The token will be a +string which the homeserver can match against its records to authenticate the +registration request. -For example, when a client attempts registration with no `auth` dict, a server may respond with: +For example, when a client attempts registration with no `auth` dict, a server +may respond with: ``` HTTP/1.1 401 Unauthorized @@ -24,7 +38,8 @@ HTTP/1.1 401 Unauthorized } ``` -The client would then prompt the user to enter a token and send a new request with an `auth` dict: +The client would then prompt the user to enter a token and send a new request +with an `auth` dict: ``` POST /_matrix/client/r0/register @@ -42,25 +57,47 @@ POST /_matrix/client/r0/register } ``` -If the server verifies that `fBVFdqVE` is a valid token then the account is registered as normal, otherwise a `401` status is returned. On the successful use of a token the server may alter the validity of the token. For example, the token may be completely invalidated, or its number of permitted uses reduced. Management of the tokens is left to the server implementation. +If the server verifies that `fBVFdqVE` is a valid token then the account is +registered as normal, otherwise a `401` status is returned. On the successful +use of a token the server may alter the validity of the token. For example, the +token may be completely invalidated, or its number of permitted uses reduced. +Management of the tokens is left to the server implementation. -Using the User-Interactive Authentication API means clients' existing registration logic will be unaffected, with a fallback available for clients without native support for the new authentication type. +Using the User-Interactive Authentication API means clients' existing +registration logic will be unaffected, with a fallback available for clients +without native support for the new authentication type. ## Potential issues -The new authentication type would only apply to the `/_matrix/client/r0/register` endpoint. This should not cause problems, but it would be worth noting in any change to the specification. +The new authentication type would only apply to the +`/_matrix/client/r0/register` endpoint. This should not cause problems, but it +would be worth noting in any change to the specification. ## Alternatives -[matrix-registration](https://github.com/ZerataX/matrix-registration/) is an application which provides token management and a standalone web interface. It uses Synapse's admin API to do registrations. +[matrix-registration](https://github.com/ZerataX/matrix-registration/) is an +application which provides token management and a standalone web interface. +It uses Synapse's admin API to do registrations. -[Midnight](https://github.com/KombuchaPrivacy/midnight) sits in front of a homeserver and handles the `/_matrix/client/r0/register` endpoint. It provides token management and does additional checks on the requested username. Registration requests are forwarded to the homeserver once authenticated. It uses the User-Interactive Authentication API in a very similar way to this MSC, which could allow existing Matrix clients to be used. +[Midnight](https://github.com/KombuchaPrivacy/midnight) sits in front of a +homeserver and handles the `/_matrix/client/r0/register` endpoint. It provides +token management and does additional checks on the requested username. +Registration requests are forwarded to the homeserver once authenticated. +It uses the User-Interactive Authentication API in a very similar way to this +MSC, which could allow existing Matrix clients to be used. -[matrix-register-bot](https://github.com/krombel/matrix-register-bot) is a Matrix bot which allows registrations done through the provided web interface to be accepted or denied by users in a certain room. When a registration is approved temporary credentials are sent to the user's verified email address. It can use Synapse's admin API or [matrix-synapse-rest-auth](https://github.com/kamax-matrix/matrix-synapse-rest-password-provider#integrate) to do the registration. +[matrix-register-bot](https://github.com/krombel/matrix-register-bot) is a +Matrix bot which allows registrations done through the provided web interface +to be accepted or denied by users in a certain room. When a registration is +approved temporary credentials are sent to the user's verified email address. +It can use Synapse's admin API or [matrix-synapse-rest-auth](https://github.com/kamax-matrix/matrix-synapse-rest-password-provider#integrate) +to do the registration. ## Unstable prefix -Implementations should use `org.matrix.msc3231.registration.token` as the authentication type until this MSC is part of a released version of the specification. +Implementations should use `org.matrix.msc3231.registration.token` as the +authentication type until this MSC is part of a released version of the +specification. From 5b93cfde173260deb4dea0b8bd04c6175514875c Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Fri, 4 Jun 2021 17:35:24 +0100 Subject: [PATCH 03/15] Link to released version of spec Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 901f166a8c6..69378b46233 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -14,8 +14,8 @@ and is integrated with existing clients. ## Proposal -The [/\_matrix/client/r0/register](https://spec.matrix.org/unstable/client-server-api/#post_matrixclientr0register) -endpoint uses the [User-Interactive Authentication API](https://spec.matrix.org/unstable/client-server-api/#user-interactive-authentication-api). +The [/\_matrix/client/r0/register](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-register) +endpoint uses the [User-Interactive Authentication API](https://matrix.org/docs/spec/client_server/r0.6.1#user-interactive-authentication-api). A new authentication type `m.registration.token` will be defined which requires a `token` key to be present in the submitted `auth` dict. The token will be a string which the homeserver can match against its records to authenticate the From 1606dc48365c3e4f694123fd91963e73da9b6139 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Fri, 4 Jun 2021 17:38:11 +0100 Subject: [PATCH 04/15] Fix unstable prefix wording Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 69378b46233..a7b316958d6 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -99,5 +99,4 @@ to do the registration. ## Unstable prefix Implementations should use `org.matrix.msc3231.registration.token` as the -authentication type until this MSC is part of a released version of the -specification. +authentication type until this MSC has passed FCP and been merged. From 5ba0996418c7cfc0c47dfce4a1acab2150ab517d Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Fri, 4 Jun 2021 17:58:22 +0100 Subject: [PATCH 05/15] Tokens should only be invalidated after registration Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index a7b316958d6..5ed69a79673 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -58,10 +58,10 @@ POST /_matrix/client/r0/register ``` If the server verifies that `fBVFdqVE` is a valid token then the account is -registered as normal, otherwise a `401` status is returned. On the successful -use of a token the server may alter the validity of the token. For example, the -token may be completely invalidated, or its number of permitted uses reduced. -Management of the tokens is left to the server implementation. +registered as normal, otherwise a `401` status is returned. Once registration of +the user has completed, the server may alter the validity of the token. +For example, the token may be completely invalidated, or its number of permitted +uses reduced. Management of the tokens is left to the server implementation. Using the User-Interactive Authentication API means clients' existing registration logic will be unaffected, with a fallback available for clients From aa8e89634a624ddf3c35268850a9a9a1393ebb23 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Fri, 4 Jun 2021 18:18:03 +0100 Subject: [PATCH 06/15] Change auth type to m.login.registration_token This is consistent with the other UIAA auth types, and does not suggest that other `m.login.*` types cannot be used for registration. Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 5ed69a79673..94caa3964c4 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -16,7 +16,7 @@ and is integrated with existing clients. The [/\_matrix/client/r0/register](https://matrix.org/docs/spec/client_server/r0.6.1#post-matrix-client-r0-register) endpoint uses the [User-Interactive Authentication API](https://matrix.org/docs/spec/client_server/r0.6.1#user-interactive-authentication-api). -A new authentication type `m.registration.token` will be defined which requires +A new authentication type `m.login.registration_token` will be defined which requires a `token` key to be present in the submitted `auth` dict. The token will be a string which the homeserver can match against its records to authenticate the registration request. @@ -30,7 +30,7 @@ HTTP/1.1 401 Unauthorized { "flows": [ { - "stages": [ "m.registration.token" ] + "stages": [ "m.login.registration_token" ] } ], "params": {}, @@ -46,7 +46,7 @@ POST /_matrix/client/r0/register { "auth": { - "type": "m.registration.token", + "type": "m.login.registration_token", "token": "fBVFdqVE", "session": "xxxxx" } @@ -98,5 +98,5 @@ to do the registration. ## Unstable prefix -Implementations should use `org.matrix.msc3231.registration.token` as the +Implementations should use `org.matrix.msc3231.login.registration_token` as the authentication type until this MSC has passed FCP and been merged. From 84b9976eb3800bbef2f2273a745decea79e9e6a3 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Mon, 7 Jun 2021 20:14:50 +0100 Subject: [PATCH 07/15] Add proposal for checking the validity of a token Signed-off-by: Callum Brown --- .../3231-token-authenticated-registration.md | 33 +++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 94caa3964c4..25b2a2ce876 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -68,6 +68,37 @@ registration logic will be unaffected, with a fallback available for clients without native support for the new authentication type. +### Checking the validity of a token + +A Client may wish to present username and password inputs only after it has +checked the token is valid. + +Clients would be able to check the validity of a token in advance of +registration with a `GET` request to +`/_matrix/client/r0/register/m.login.registration_token/validity`. +This endpoint would take a `token` query parameter, and validity would be +indicated by the boolean `valid` key in the response. + +For example, a client would send: + +``` +GET /_matrix/client/r0/register/m.login.registration_token/validity?token=abcd +``` + +If `abcd` is a valid token, the server would respond with: + +``` +HTTP/1.1 200 OK + +{ + "valid": true +} +``` + +This does not perform any actual authentication, and the validity of the token +may change between the check and the User-Interactive Authentication. + + ## Potential issues The new authentication type would only apply to the @@ -100,3 +131,5 @@ to do the registration. Implementations should use `org.matrix.msc3231.login.registration_token` as the authentication type until this MSC has passed FCP and been merged. +Similarly, `/_matrix/client/r0/register/org.matrix.msc3231.login.registration_token/validity` +should be used as the endpoint for checking the validity of a token in advance. From 7e7352589a75afbc679255fe209174b0cdc304f4 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Thu, 10 Jun 2021 21:31:42 +0100 Subject: [PATCH 08/15] Fix validity checking endpoint Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 25b2a2ce876..062ec3f98b5 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -75,14 +75,14 @@ checked the token is valid. Clients would be able to check the validity of a token in advance of registration with a `GET` request to -`/_matrix/client/r0/register/m.login.registration_token/validity`. -This endpoint would take a `token` query parameter, and validity would be +`/_matrix/client/v1/register/m.login.registration_token/validity`. +This endpoint would take a required `token` query parameter, and validity would be indicated by the boolean `valid` key in the response. For example, a client would send: ``` -GET /_matrix/client/r0/register/m.login.registration_token/validity?token=abcd +GET /_matrix/client/v1/register/m.login.registration_token/validity?token=abcd ``` If `abcd` is a valid token, the server would respond with: @@ -131,5 +131,5 @@ to do the registration. Implementations should use `org.matrix.msc3231.login.registration_token` as the authentication type until this MSC has passed FCP and been merged. -Similarly, `/_matrix/client/r0/register/org.matrix.msc3231.login.registration_token/validity` +Similarly, `/_matrix/client/unstable/org.matrix.msc2321/register/org.matrix.msc3231.login.registration_token/validity` should be used as the endpoint for checking the validity of a token in advance. From 22f1f93ed7a5ea97259a33b1f14787edb13bf119 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Thu, 10 Jun 2021 22:13:59 +0100 Subject: [PATCH 09/15] Limit allowed characters and length of token This allows tokens to be used easily in query parameters Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 062ec3f98b5..53f21cee64f 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -18,8 +18,8 @@ The [/\_matrix/client/r0/register](https://matrix.org/docs/spec/client_server/r0 endpoint uses the [User-Interactive Authentication API](https://matrix.org/docs/spec/client_server/r0.6.1#user-interactive-authentication-api). A new authentication type `m.login.registration_token` will be defined which requires a `token` key to be present in the submitted `auth` dict. The token will be a -string which the homeserver can match against its records to authenticate the -registration request. +string of no more than 64 characters, and contain only characters matched by the +regex `[A-Za-z0-9-_]`. For example, when a client attempts registration with no `auth` dict, a server may respond with: From 32a9c01b6bbe7e9b810d09618ecf74a505a17ed3 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Wed, 16 Jun 2021 16:53:33 +0100 Subject: [PATCH 10/15] Give reason for limiting token length and chars Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 53f21cee64f..ad4a49314e4 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -20,6 +20,8 @@ A new authentication type `m.login.registration_token` will be defined which req a `token` key to be present in the submitted `auth` dict. The token will be a string of no more than 64 characters, and contain only characters matched by the regex `[A-Za-z0-9-_]`. +This will avoid URL encoding issues with the validity checking endpoint, and +prevent DoS attacks from extremely long tokens. For example, when a client attempts registration with no `auth` dict, a server may respond with: From 80fc0ed27c90becae7f2d596c9bb64f45611156e Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Wed, 16 Jun 2021 17:50:46 +0100 Subject: [PATCH 11/15] Note all stages must be complete for registration Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/3231-token-authenticated-registration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index ad4a49314e4..4016e648549 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -60,7 +60,7 @@ POST /_matrix/client/r0/register ``` If the server verifies that `fBVFdqVE` is a valid token then the account is -registered as normal, otherwise a `401` status is returned. Once registration of +registered as normal assuming all other required auth stages have been completed, otherwise a `401` status is returned. Once registration of the user has completed, the server may alter the validity of the token. For example, the token may be completely invalidated, or its number of permitted uses reduced. Management of the tokens is left to the server implementation. From 88edde669fb7d352cd8039e99c4f2d95136051e7 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Fri, 18 Jun 2021 12:36:40 +0100 Subject: [PATCH 12/15] Fix mistake in MSC number Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 4016e648549..7f58910e175 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -133,5 +133,5 @@ to do the registration. Implementations should use `org.matrix.msc3231.login.registration_token` as the authentication type until this MSC has passed FCP and been merged. -Similarly, `/_matrix/client/unstable/org.matrix.msc2321/register/org.matrix.msc3231.login.registration_token/validity` +Similarly, `/_matrix/client/unstable/org.matrix.msc3231/register/org.matrix.msc3231.login.registration_token/validity` should be used as the endpoint for checking the validity of a token in advance. From 2433c9fa7a4fb80a0f41691cbcf261f9e8e26ab5 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Mon, 30 Aug 2021 16:44:50 +0100 Subject: [PATCH 13/15] Validity checking should be rate limited Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 1 + 1 file changed, 1 insertion(+) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 7f58910e175..01d11b2053c 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -100,6 +100,7 @@ HTTP/1.1 200 OK This does not perform any actual authentication, and the validity of the token may change between the check and the User-Interactive Authentication. +This endpoint should be rate limited in order to prevent dictionary attacks. ## Potential issues From 5eb8a8b2991a34083ce9803c054e27ba443ff551 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Wed, 8 Sep 2021 09:59:21 +0100 Subject: [PATCH 14/15] Change v1 to r0 Signed-off-by: Callum Brown --- proposals/3231-token-authenticated-registration.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 01d11b2053c..0b35c104e23 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -77,14 +77,14 @@ checked the token is valid. Clients would be able to check the validity of a token in advance of registration with a `GET` request to -`/_matrix/client/v1/register/m.login.registration_token/validity`. +`/_matrix/client/r0/register/m.login.registration_token/validity`. This endpoint would take a required `token` query parameter, and validity would be indicated by the boolean `valid` key in the response. For example, a client would send: ``` -GET /_matrix/client/v1/register/m.login.registration_token/validity?token=abcd +GET /_matrix/client/r0/register/m.login.registration_token/validity?token=abcd ``` If `abcd` is a valid token, the server would respond with: From 79939f955b34113404b5d363a981f790aa7ec0e7 Mon Sep 17 00:00:00 2001 From: Callum Brown Date: Wed, 22 Sep 2021 16:58:47 +0100 Subject: [PATCH 15/15] Include `.` and `~` in allowed characters for registration tokens For consistency with the unreserved URL characters in RFC3986 https://www.ietf.org/rfc/rfc3986.html#section-2.3 Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/3231-token-authenticated-registration.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3231-token-authenticated-registration.md b/proposals/3231-token-authenticated-registration.md index 0b35c104e23..a86b9fbc53f 100644 --- a/proposals/3231-token-authenticated-registration.md +++ b/proposals/3231-token-authenticated-registration.md @@ -19,7 +19,7 @@ endpoint uses the [User-Interactive Authentication API](https://matrix.org/docs/ A new authentication type `m.login.registration_token` will be defined which requires a `token` key to be present in the submitted `auth` dict. The token will be a string of no more than 64 characters, and contain only characters matched by the -regex `[A-Za-z0-9-_]`. +regex `[A-Za-z0-9._~-]`. This will avoid URL encoding issues with the validity checking endpoint, and prevent DoS attacks from extremely long tokens.