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

fix: openid ignores missing redirect uri #762

Closed

Conversation

james-d-elliott
Copy link
Contributor

@james-d-elliott james-d-elliott commented Aug 4, 2023

Fixes an issue where Authorize Requests which were intended for an OpenID Connect 1.0 client would incorrectly be allowed when missing the redirect URI when it's required by the specification.

Related Issue or Design Document

Fixes #685

Checklist

  • I have read the contributing guidelines and signed the CLA.
  • I have referenced an issue containing the design document if my change introduces a new feature.
  • I have read the security policy.
  • I confirm that this pull request does not address a security vulnerability.
    If this pull request addresses a security vulnerability,
    I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added the necessary documentation within the code base (if appropriate).

Further comments

The added tests fail prior to the fix and pass after.

@james-d-elliott james-d-elliott marked this pull request as ready for review August 4, 2023 05:17
Fixes an issue where Authorize Requests which were intended for an OpenID Connect 1.0 client would incorrectly be allowed when missing the redirect URI when it's required by the specification.
// Hybrid Flow - https://openid.net/specs/openid-connect-core-1_0.html#HybridAuthRequest
//
// Note: as per the Hybrid Flow documentation the Hybrid Flow has the same requirements as the Authorization Code Flow.
if len(rawRedirURI) == 0 && request.GetRequestedScopes().Has("openid") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this not already handled by the openid handler itself?

Copy link
Contributor Author

@james-d-elliott james-d-elliott Aug 30, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added an integration test which shows this is unfortunately not the case. It only returns an error if the client has multiple redirect URI's. The issue is that OAuth 2.0 allows assuming the Redirect URI if absent provided there is only one, however OpenID Connect 1.0 explicitly requires the redirect URI parameter and has no such leeway.

It should also be noted that OAuth 2.1 does not alter this behavior and instead elaborates / clarifies the behavior for better or worse. The only alteration by my reading is in OpenID Connect 1.0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also see the linked issue, you were actually the person to raise the issue. Maybe that's helpful?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked this and I agree with @james-d-elliott: OAuth 2.0 says that if you included Redirect URI in authentication request, then it has also be included in the token request. And Fosite currently checks that.

But OIDC spec says that Redirect URI is required in the authentication request. And this PR adds this check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you both - I checked and indeed the expectation is that the redirect-url is properly validated before we call HandleAuthorizeEndpointRequest. Given that this is openID specific though, this should be moved to the openid handler instead. I'll do that now

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm creating a separate PR as this is a breaking change for existing clients and it requires dedicated care for merging that to production on our infrastructure!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I can tell, this implementation does not respect hybrid or implicit flows of OIDC, so it definitely makes sense to move that to the appropriate handlers in my view.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like a solid plan, glad this will get merged regardless.

return request, err
}

if err := f.validateResponseMode(r, request); err != nil {
if err = f.validateResponseMode(r, request); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why these changes? I think they are unrelated and just change the style?

@@ -363,27 +378,31 @@ func (f *Fosite) newAuthorizeRequest(ctx context.Context, r *http.Request, isPAR
return request, err
}

if err := f.validateAuthorizeRedirectURI(r, request); err != nil {
if err = f.parseAuthorizeScope(r, request); err != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that instead of splitting validateAuthorizeScope into parseAuthorizeScope and validateAuthorizeScope, it would be easier if you swapped the order of validation, first call (original) validateAuthorizeScope and then (updated) validateAuthorizeRedirectURI. In a way, if validateAuthorizeRedirectURI depends on parsed scopes, it is better if validateAuthorizeRedirectURI depends on parsed and validated scopes.

Fixes an issue where Authorize Requests which were intended for an OpenID Connect 1.0 client would incorrectly be allowed when missing the redirect URI when it's required by the specification.

Closes ory#685
Closes ory#762

BREAKING CHANGES: Going forward, calls to `/oauth2/auth` which trigger OpenID Connect require the `redirect_uri` query parameter to be set.
@aeneasr
Copy link
Member

aeneasr commented Jul 9, 2024

Closing in favor of #814

@aeneasr aeneasr closed this Jul 9, 2024
aeneasr added a commit that referenced this pull request Sep 16, 2024
Fixes an issue where Authorize Requests which were intended for an OpenID Connect 1.0 client would incorrectly be allowed when missing the redirect URI when it's required by the specification.

Closes #685
Closes #762

BREAKING CHANGES: Going forward, calls to `/oauth2/auth` which trigger OpenID Connect require the `redirect_uri` query parameter to be set.
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

Successfully merging this pull request may close these issues.

Investigate missing redirect_uri check when performing OIDC flows
3 participants