[WIP] MSC2966: Usage of OAuth 2.0 Dynamic Client Registration in Matrix

[sandhose]

Rendered

Dependencies:

• MSC3861: Matrix architecture change to delegate authentication via OIDC #3861

[richvdh]

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?

[sandhose]

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.

[richvdh]

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?

[richvdh]

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.

[deepbluev7]

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]

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]

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.

[MTRNord]

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]

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]

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]

Why is this a problem?

[MTRNord]

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]

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.