-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OAUTH: how does a client manage multiple version of its metadata at the same time? #51
Comments
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 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. |
I don't really see how In our implementation, the 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. |
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. |
My project ran into this issue as well, but the IndieAuth spec is changing to become properly OIDC compatible: indieweb/indieauth#133 There’s also this: https://drafts.aaronpk.com/draft-parecki-oauth-client-id-metadata-document/draft-parecki-oauth-client-id-metadata-document.html |
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 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 |
So, we've settled on implementing aaronpk/draft-parecki-oauth-client-id-metadata-document#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. |
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_id
s, e.g.v1.example.com
andv2.example.com
, which would resolve to different client metadata, but then I presume that would break existing sessions whenever you upgrade the app, as theclient_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 7800cnf
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 somewhereBy 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.
The text was updated successfully, but these errors were encountered: