-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Feat: Implement oauth authorization server metadata #1737
base: main
Are you sure you want to change the base?
Feat: Implement oauth authorization server metadata #1737
Conversation
…ed code challenge methods
… tests and console
@nbulaj @ransombriggs would love some feedback on my implementation proposal in the PR description — I think that's the right way forwards, but haven't yet begun to implement. |
I would give feedback but I am not familiar with https://www.rfc-editor.org/rfc/rfc8414 and really just a bystander on this project. I got it to do what I needed and then was moved onto other things. |
I have some feeling that the work should be done inside https://github.com/doorkeeper-gem/doorkeeper-openid_connect 🤔 I remember it handles all these stuff around Discovery and related. Have to recheck deeply |
RFC 8414 is part of OAuth and is separate from OIDC's Discovery, but is compatible in some ways. RFC 8414 uses |
Summary
This is early work on supporting #1587, it's currently based off an older commit from #1732, #1735, and #1736 since those allow me to work semi-productively on the doorkeeper codebase.
I'm unsure if we'd really need a custom controller for discovery, as I think the initializer for configuration should probably handle the "adding extra stuff to the
.well-known/oauth-authorization-server
endpoint, instead of actually overriding the controller.I don't think it makes sense for the
scope
option with doorkeeper to affect the.well-known/oauth-authorization-server
endpoint, however, nesting that within a scope can work (allowing multiple oauth providers on the one domain, similar to how keycloak works)I'm still to figure out all the necessary stuff for actually building out the data for response. I think I'm probably inclined to create a
Doorkeeper::OAuth::DiscoveryResponse
class, and acustom_discovery_response
configuration block option, then have the controller just apply that class.There's also the question of "should this be rename-able by other plugins?", e.g., OIDC that uses
.well-known/openid-configuration
instead of.well-known/oauth-authorization-server
— I'd probably guess maybe no, and instead the OIDC plugin could just remove the.well-known/oauth-authorization-server
route and add its own which is calling a subclass ofDoorkeeper::OAuth::DiscoveryResponse
?