Skip to content
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

Support RFC 7591 - Dynamic Client Registration #80

Open
thibaultamartin opened this issue Feb 27, 2020 · 3 comments
Open

Support RFC 7591 - Dynamic Client Registration #80

thibaultamartin opened this issue Feb 27, 2020 · 3 comments
Labels
feature Unimplemented addition

Comments

@thibaultamartin
Copy link

thibaultamartin commented Feb 27, 2020

Feature

This RFC itself is quite short, implementing the (client registration endpoint will do the trick.

Context

OAuth2 is a framework that works great but needs clients to handle a client_id and sometimes client_secret. While this is not a problem with centralized services, this easily becomes a limitation for self-hosted solutions. Trying to register a Wallabag app against a Wallabag self-hosted instance can give you a good idea of how difficult it is for end-users.

Fortunately, the RFC 7591 - Dynamic Client Registration allows clients to ask the server for a client_id and client_secret, making it easy to use for end-users of self-hosted apps.

Alternatives

As a former UK PM said, there is no alternative

@thibaultamartin thibaultamartin added the feature Unimplemented addition label Feb 27, 2020
@thespooler
Copy link
Contributor

Good idea, but I believe it to be out of scope for the current project.
This would imply a storage backend.
I can't talk for the author, but it seems to me that this library aims to not force choices regarding web framework and storage technologies for the developper.
You could of course quite easily implement that as a custom Registrar (see ClientMap impl).

@Sytten
Copy link

Sytten commented Jul 12, 2022

I want to revisit this issue. I believe the library could include the endpoint / business logic portion like it does for other endpoints and let the pluggable backend handle the storage.
We happen to need this flow so I will try to implement it in a fork.

@HeroicKatora
Copy link
Owner

Nice. It does sound feasible to stay true to the scope if the persistent implementation of the extended registrar primitive lives in a separate crate. Keep us updated on progress and if you'd like any maintainer inputs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Unimplemented addition
Projects
None yet
Development

No branches or pull requests

4 participants