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

Automatically set (and send?) redirect_uri #136

Open
nevans opened this issue Nov 30, 2022 · 2 comments
Open

Automatically set (and send?) redirect_uri #136

nevans opened this issue Nov 30, 2022 · 2 comments

Comments

@nevans
Copy link

nevans commented Nov 30, 2022

To match the omniauth-oauth2 gem and the gems that subclass it, and to simplify valid provider configuration, the redirect_uri should be automatically configured to "callback_uri". To maintain backward compatibility (and allow customization) it would only be set when missing, and never override an explicit configuration.

Although RFC-6749 considers redirect_uri to be optional, the OIDC Core spec marks it as required. So there's really no circumstance it should not be sent to the authorization endpoint (which is what happens if it isn't explicitly configured).

What do you think? Would a PR that does this be accepted?

@lfdebrux
Copy link

+1 I would also like this feature.

lfdebrux added a commit to alphagov/forms-admin that referenced this issue Jun 30, 2023
For some reason the omniauth_openid_connect gem wants us to supply the
`redirect_uri` (the URL to redirect to after a successful OAuth2
negotiation, which in our case is the OmniAuth callback route) when the
provider is configured. This is really annoying to do, and I can't see
why it wouldn't be able to use the OmniAuth `callback_url` in the same
way the omniauth-oauth2 gem does [[1]]. There is an open feature request
for this [[2]], but it hasn't been acknowledged by the maintainers as
yet. So instead we'll just monkeypatch the strategy.

[1]: https://github.com/omniauth/omniauth-oauth2/blob/3a43234ab5dd36a75f9c125c58fcfe1a37b26805/lib/omniauth/strategies/oauth2.rb#L59
[2]: omniauth/omniauth_openid_connect#136 (comment)
lfdebrux added a commit to alphagov/forms-admin that referenced this issue Jun 30, 2023
For some reason the omniauth_openid_connect gem wants us to supply the
`redirect_uri` (the URL to redirect to after a successful OAuth2
negotiation, which in our case is the OmniAuth callback route) when the
provider is configured. This is really annoying to do, and I can't see
why it wouldn't be able to use the OmniAuth `callback_url` in the same
way the omniauth-oauth2 gem does [[1]]. There is an open feature request
for this [[2]], but it hasn't been acknowledged by the maintainers as
yet. So instead we'll just monkeypatch the strategy.

[1]: https://github.com/omniauth/omniauth-oauth2/blob/3a43234ab5dd36a75f9c125c58fcfe1a37b26805/lib/omniauth/strategies/oauth2.rb#L59
[2]: omniauth/omniauth_openid_connect#136 (comment)
lfdebrux added a commit to alphagov/forms-admin that referenced this issue Jul 6, 2023
For some reason the omniauth_openid_connect gem wants us to supply the
`redirect_uri` (the URL to redirect to after a successful OAuth2
negotiation, which in our case is the OmniAuth callback route) when the
provider is configured. This is really annoying to do, and I can't see
why it wouldn't be able to use the OmniAuth `callback_url` in the same
way the omniauth-oauth2 gem does [[1]]. There is an open feature request
for this [[2]], but it hasn't been acknowledged by the maintainers as
yet. So instead we'll just monkeypatch the strategy.

[1]: https://github.com/omniauth/omniauth-oauth2/blob/3a43234ab5dd36a75f9c125c58fcfe1a37b26805/lib/omniauth/strategies/oauth2.rb#L59
[2]: omniauth/omniauth_openid_connect#136 (comment)
@exciton
Copy link

exciton commented Sep 7, 2023

Can confirm the monkey patch works to enable deleting redirect_uri from client_options.

class OmniAuth::Strategies::OpenIDConnect
  def redirect_uri
    full_host + callback_path
  end
end

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

No branches or pull requests

3 participants