MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix #2966

sandhose · 2021-01-14T17:12:16Z

Dependencies:

MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC #3861

richvdh · 2021-02-04T10:35:49Z

proposals/2966-oauth2-dynamic-registration.md

+| `contacts`       | Array of strings representing ways to contact people responsible for this client, typically email addresses | Required                                         | No          |
+| `tos_uri`        | URL that points to a human-readable terms of service document for the client                                | Required                                         | Yes         |
+| `policy_uri`     | URL that points to a human-readable policy document for the client                                          | Required                                         | Yes         |
+| `redirect_uris`  | Array of redirection URIs for use in redirect-based flows                                                   | Required with the `authorization_code` grant ype | No          |


something I don't really understand here (or about OAuth2 dynamic registration in general):

What is to stop me, as an attacker, registering a "client" with branding (name, logo, etc) that looks like a trusted client, but with a redirect_uri that points to a site I control?

I then send the user a link which will take them through the login flow, and redirect back to my site. Assuming I can persaude the user to open the link, I can then harvest the authorization code and thence gain access to their account?

In this case the auth server would at least prompt for explicit consent as it would be considered as a separate client from the legitimate one.

One thing that could be enforced would be to have the different URIs (at least redirect_uris and client_uri) to be on the same origin. Quoting from RFC 7591 sec. 5:

In a situation where the authorization server is supporting open client registration, it must be extremely careful with any URL provided by the client that will be displayed to the user (e.g., logo_uri, tos_uri, client_uri, and policy_uri). For instance, a rogue client could specify a registration request with a reference to a drive-by download in the policy_uri, enticing the user to click on it during the authorization. The authorization server SHOULD check to see if the logo_uri, tos_uri, client_uri, and policy_uri have the same host and scheme as the those defined in the array of redirect_uris and that all of these URIs resolve to valid web pages.

In this case the auth server would at least prompt for explicit consent as it would be considered as a separate client from the legitimate one.

of course; but how is the user meant to tell that they are now being asked for consent to a phishing app?

One thing that could be enforced would be to have the different URIs (at least redirect_uris and client_uri) to be on the same origin.

Wouldn't this preclude the use of desktop clients, which often register custom URI schemes to get the auth code back from a browser to the client?

As discussed elsewhere: it turns out that on Windows and MacOS at least, desktop apps can register for parts of the https:// namespace. So that only really leaves Linux where you can only register for an entire URI scheme (via an x-scheme-handler/... mimetype).

So it should be possible to create a system which makes this look user-friendly for everyone except Linux users, who presumably are a bit more comfortable with obscure URIs anyway.

My client generates a localhost address on demand during SSO currently. This MSC makes it sound like I need to switch to a fixed schema instead, which means running multiple instances of my software in parallel will become much harder. How would I solve having 2 separate instances of my app running and I want to only sign into one of them?

richvdh · 2021-02-13T13:29:26Z

proposals/2966-oauth2-dynamic-registration.md

+## Proposal
+
+If a Matrix server wants to be used by any third-party client, its authentication server must allow dynamic registration of OAuth 2.0 clients.
+The client registration endpoint is advertised in the OIDC discovery document and can be used as per [RFC 7591 sec. 3](https://tools.ietf.org/html/rfc7591#section-3).


I'm sure this is obvious if you're familiar with OAuth2, but for context I'd find it really helpful if you could clarify when a client would register itself with a given server in the context of Matrix. Presumably, whenever the user chooses a homeserver to log into? (Is the client expected to remember a list of homeservers it has registered against?)

deepbluev7 · 2023-02-24T15:31:39Z

proposals/2966-oauth2-dynamic-registration.md

+| `contacts`       | Array of strings representing ways to contact people responsible for this client, typically email addresses | Required                                         | No          |
+| `tos_uri`        | URL that points to a human-readable terms of service document for the client                                | Required                                         | Yes         |
+| `policy_uri`     | URL that points to a human-readable policy document for the client                                          | Required                                         | Yes         |


Does this mean, that for any client I develop, I now need infrastructure and domains to host these documents, as I assume these need to be web accessible? Currently you don't need any of that, since the client doesn't send any data to the client developer and doesn't provide any service, where ToS make any sense. But now to be able to sign in with my self written client, I need to host a website? That doesn't sound like "Simpler for Homeservers and clients to implement" from MSC3861 at all.

Also often community clients are deliberately NOT a service provider. So why would they need a ToS if there is no Service?

For example Apache2 comes with this disclaimer in the license:

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

So clearly there is no service provided.

deepbluev7 · 2023-02-24T15:37:54Z

proposals/2966-oauth2-dynamic-registration.md

+| `contacts`       | Array of strings representing ways to contact people responsible for this client, typically email addresses | Required                                         | No          |
+| `tos_uri`        | URL that points to a human-readable terms of service document for the client                                | Required                                         | Yes         |
+| `policy_uri`     | URL that points to a human-readable policy document for the client                                          | Required                                         | Yes         |
+| `redirect_uris`  | Array of redirection URIs for use in redirect-based flows                                                   | Required with the `authorization_code` grant ype | No          |


My client generates a localhost address on demand during SSO currently. This MSC makes it sound like I need to switch to a fixed schema instead, which means running multiple instances of my software in parallel will become much harder. How would I solve having 2 separate instances of my app running and I want to only sign into one of them?

deepbluev7 · 2023-02-24T15:53:42Z

proposals/2966-oauth2-dynamic-registration.md

+To securely identify themselves, clients must send a digitally signed version of their metadata.
+This is done by encoding the client metadata in a JWT and signing it.


How do I include such data in my open-source project? Because this would allow either everyone to make themselves look like my client or I can't distribute my software freely anymore, can I? Is there some documentation on why this is secure for desktop applications, that I could read? Or what "securely identify" means in this context as in what it is protecting against?

deepbluev7 · 2023-02-24T15:54:34Z

proposals/2966-oauth2-dynamic-registration.md

+If a client changes its `redirect_uris`, should the old ones be considered for a period of time?
+If multiple versions of the same client coexist at the same time, should older versions of the software be able to override the metadata of the newer version?
+
+If an authorization server allows unsigned clients, the number of client registration might explode exponentially.


Why is this a problem?

I don't think this should be problem, imho. This is the whole goal of an open ecosystem like matrix. Anyone at any time can build a client and use it. You are not vendor bound. Allowing this to be restricted imho goes against the core idea of an open ecosystem which matrix tries to be.

Edit also see: #3861 (comment)

zecakeh · 2023-08-04T13:06:04Z

proposals/2966-oauth2-dynamic-registration.md

+### Metadata signature
+
+To securely identify themselves, clients must send a digitally signed version of their metadata.
+This is done by encoding the client metadata in a JWT and signing it.


It is not said how the JWT is sent during registration. Looking at RFC7591, my guess is this what is called a software statement, but it should be said clearly.

…tration

- makes some metadata optional - better explain how each metadata field is used - better explain what the restrictions on redirect_uris are - remove the signed metadata part - mention the client metadata JSON document alternative

tonkku107 · 2024-09-17T13:45:17Z

proposals/2966-oauth2-dynamic-registration.md

+
+This proposal requires the client to know the following authorization server metadata about the homeserver:
+
+ - `registration_endpoint`: the URL where the user is able to access the client registration endpoint.


Suggested change

- `registration_endpoint`: the URL where the user is able to access the client registration endpoint.

- `registration_endpoint`: the URL where the client is able to register itself.

Again this endpoint isn't interacting with users but clients and could be explained better

tonkku107 · 2024-09-17T14:13:26Z

proposals/2966-oauth2-dynamic-registration.md

+It is recommended that the `client_uri` is a web page that provides information about the client.
+This page should be able to be accessed without requiring authentication.
+
+This URI is a common base for all the other URIs in the metadata: those must be either on the same host or on a subdomain of the host of the `client_uri`.
+For example, if the `client_uri` is `https://example.com/`, then one of the `redirect_uris` can be `https://example.com/callback` or `https://app.example.com/callback`, but not `https://app.com/callback`.


For a self-hostable web client like Element web, the recommended uri would be element.io but if I host an instance of it on example.com, I wouldn't be able to set a proper redirect_uri with the recommended uri.
How important is this requirement really? What about informing the user about the differing host in the redirect uri during authorization?
Of course clients could also bundle in their landing pages and policies or set up a redirect to work around the issue.

tonkku107 · 2024-09-17T14:16:10Z

proposals/2966-oauth2-dynamic-registration.md

+ - `response_types`: Array of the OAuth 2.0 response types that the client may use
+ - `grant_types`: Array of OAuth 2.0 grant types that the client may use
+
+To use this grant, along with refresh tokens:


This makes it sound like the items below are extra requirements to get a refresh token

tonkku107 · 2024-09-17T14:20:31Z

proposals/2966-oauth2-dynamic-registration.md

+}
+```
+
+**Note**: in this example, the server has not registered the locale-specific values for `client_name`, `tos_uri`, and `policy_uri`, which is why they are not present in the response.


Maybe it'd be useful to add examples which show that the server could ignore any values, not just localized ones (except required values specified in this MSC) or choose to modify values. For example a homeserver could ignore the grant_types sent by the client and register that it has access to any supported grant_types for a simpler implementation (at least according to RFC 7591)

The authorization server MAY reject or
replace any of the client's requested metadata values submitted
during the registration and substitute them with suitable values.
The client or developer can check the values in the response to
determine if the registration is sufficient for use

OAuth 2.0 Dynamic Registration MSC

1b1bcdd

turt2live changed the title ~~MSC2966: [WIP] Usage of OAuth 2.0 Dynamic Client Registration in Matrix~~ [WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix Jan 14, 2021

turt2live marked this pull request as draft January 14, 2021 17:28

turt2live added kind:feature MSC for not-core and not-maintenance stuff proposal A matrix spec change proposal labels Jan 14, 2021

sandhose mentioned this pull request Jan 15, 2021

MSC2964: Usage of OAuth 2.0 authorization code grant and refresh token grant #2964

Open

9 tasks

richvdh reviewed Feb 4, 2021

View reviewed changes

richvdh reviewed Feb 13, 2021

View reviewed changes

turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Jun 8, 2021

turt2live force-pushed the old_master branch from e895827 to dca99ee Compare August 30, 2021 22:34

sandhose mentioned this pull request Jan 17, 2022

Support dynamic client registration matrix-org/matrix-authentication-service#17

Closed

39 tasks

hughns mentioned this pull request Aug 4, 2022

MSC3861: Next-generation auth for Matrix, based on OAuth 2.0/OIDC #3861

Draft

deepbluev7 reviewed Feb 24, 2023

View reviewed changes

turt2live added the matrix-2.0 Required for Matrix 2.0 label Mar 3, 2023

zecakeh reviewed Aug 4, 2023

View reviewed changes

contacts is required non-empty

d923a45

This was referenced Sep 7, 2023

Required MSC2966 contacts field is missing from OIDC client registration element-hq/element-x-ios#1653

Closed

Required MSC2966 contacts field is missing from OIDC client registration element-hq/element-x-android#1250

Closed

Make client_uri mandatory

2bdcc4a

sandhose mentioned this pull request Feb 7, 2024

OAUTH: how does a client manage multiple version of its metadata at the same time? bluesky-social/proposals#51

Open

Merge branch 'matrix-org:main' into msc/sandhose/oauth2-dynamic-regis…

d4caa5a

…tration

sandhose closed this Sep 3, 2024

sandhose deleted the msc/sandhose/oauth2-dynamic-registration branch September 3, 2024 10:23

sandhose restored the msc/sandhose/oauth2-dynamic-registration branch September 3, 2024 10:24

sandhose reopened this Sep 3, 2024

sandhose changed the base branch from old_master to main September 3, 2024 10:25

matrixbot mentioned this pull request Sep 9, 2024

Support dynamic client registration element-hq/matrix-authentication-service#17

Closed

39 tasks

Rework MSC

32c9ead

- makes some metadata optional - better explain how each metadata field is used - better explain what the restrictions on redirect_uris are - remove the signed metadata part - mention the client metadata JSON document alternative

sandhose changed the title ~~[WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix~~ MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix Sep 13, 2024

sandhose marked this pull request as ready for review September 13, 2024 15:41

tonkku107 reviewed Sep 17, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix #2966

MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix #2966

sandhose commented Jan 14, 2021 •

edited by hughns

Loading

richvdh Feb 4, 2021

sandhose Feb 4, 2021

richvdh Feb 4, 2021

richvdh Feb 13, 2021

deepbluev7 Feb 24, 2023

richvdh Feb 13, 2021

deepbluev7 Feb 24, 2023

MTRNord Feb 24, 2023

deepbluev7 Feb 24, 2023

deepbluev7 Feb 24, 2023

deepbluev7 Feb 24, 2023

MTRNord Feb 24, 2023 •

edited

Loading

zecakeh Aug 4, 2023

tonkku107 Sep 17, 2024

tonkku107 Sep 17, 2024

tonkku107 Sep 17, 2024

tonkku107 Sep 17, 2024 •

edited

Loading

		To securely identify themselves, clients must send a digitally signed version of their metadata.
		This is done by encoding the client metadata in a JWT and signing it.


		This proposal requires the client to know the following authorization server metadata about the homeserver:

		- `registration_endpoint`: the URL where the user is able to access the client registration endpoint.

MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix #2966

Are you sure you want to change the base?

MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix #2966

Conversation

sandhose commented Jan 14, 2021 • edited by hughns Loading

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

MTRNord Feb 24, 2023 • edited Loading

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

tonkku107 Sep 17, 2024 • edited Loading

Choose a reason for hiding this comment

sandhose commented Jan 14, 2021 •

edited by hughns

Loading

MTRNord Feb 24, 2023 •

edited

Loading

tonkku107 Sep 17, 2024 •

edited

Loading