search

bluesky-social / proposals

Bluesky proposal discussions
88 stars 9 forks source link

OAUTH: how does a client manage multiple version of its metadata at the same time? #51

Open sandhose opened 7 months ago

sandhose commented 7 months ago

A client may want to change its client metadata, for example, to add or remove a scope, or change its redirect_uris.

Because you don't always control the rollout of new versions of your application, how does one manage to maintain two versions of the same application with potentially different client metadata?

You could set different client_ids, e.g. v1.example.com and v2.example.com, which would resolve to different client metadata, but then I presume that would break existing sessions whenever you upgrade the app, as the client_id is different?

Having faced the same problem for the Matrix protocol, an alternative would be to use dynamic client registration, with a software_statement, self-signed using RFC 7800 cnf method. Then the server can use the (cnf, software_id, software_version) tuple to dedupe clients and track client version updates. I still need to write up the real proposal in a public document somewhere

By the way, this client registration problem in a decentralised web is not new, and IndieAuth tried to solve that some time ago, but we dismissed this for Matrix because it was too different from the rest of the OAuth & OIDC specs, was too opinionated also for the auth server part, and was quite lacking in terms of what metadata you could define.

matthieusieben commented 6 months ago

Hi ! Thank you for your message & interest.

Our current position about the rollout of different versions is as follows: Before the rollout of a new version starts, the client metadata can be updated to include additional required scopes and/or redirect_uris. This broader client metadata can then be updated again to a stricter version once the rollout is over.

We also looked into IndieAuth and dismissed it for the same reason. We realized after writing our proposal that there already exists a Draft that does something very similar as we did. We are actively looking into bringing this draft back up and we will try to match whatever spec comes out of it.

matthieusieben commented 6 months ago

I don't really see how software_statements could help with this. software_id is used to identify client instances, and the key used to sign the software_statement can indeed be used as means for clients to prove they are indeed the owner of that software_id. Our implementation does not need any of that. The reason is that our trust model works differently and relies on DNS to verify ownership.

In our implementation, the client_id (= +/- client_uri) acts as a software_id. And the fact that the metadata can be obtained, on the internet, form an endpoint derived from the client_id, serves as "proof" that the owner of the software_id is indeed who he claims to be.

Domain name owners can change, of course, but then so will the private key of the client, which will result in all credentials being invalidated for that client.

matthieusieben commented 6 months ago

Clients who do not wish to allow a broader client metadata to exist should handle authentication failures as being possibly cause by an outdated version of the client (requesting scopes/redirect_uris no longer valid) and prompt the user to update the client.

erlend-sh commented 3 months ago

By the way, this client registration problem in a decentralised web is not new, and IndieAuth tried to solve that some time ago, but we dismissed this for Matrix because it was too different from the rest of the OAuth & OIDC specs

My project ran into this issue as well, but the IndieAuth spec is changing to become properly OIDC compatible: https://github.com/indieweb/indieauth/issues/133

There’s also this: https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html

ThisIsMissEm commented 3 months ago

I'm one of the authors of https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html

It's already compatible with Solid-OIDC Client Identifier Documents, and provides more flexibility than just hostname based client_ids. We are working through caching concerns here: https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/issues/3

You don't really want to be changing the client_id If it's the same client, since they'd resolve to different clients then. But we do need to figure out a way to say "hey, this may not be the latest document" perhaps by sending the IdP / AS a request to invalidate the document or relying on cache-control headers

matthieusieben commented 3 months ago

So, we've settled on implementing https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document/issues/3 in the initial version of OAuth for ATPROTO (we'll update the proposal accordingly).

There are still a few concerns with the document in its current form, but we'll raise them in the https://github.com/aaronpk/draft-parecki-oauth-client-id-metadata-document repo.