-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
Changes from all commits
4273501
63c797c
37f4ada
14f50b3
86c8ea5
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -165,6 +165,17 @@ func (f *Fosite) validateAuthorizeRedirectURI(_ *http.Request, request *Authoriz | |
// Fetch redirect URI from request | ||
rawRedirURI := request.Form.Get("redirect_uri") | ||
|
||
// This ensures that the 'redirect_uri' parameter is present for OpenID Connect 1.0 authorization requests as per: | ||
// | ||
// Authorization Code Flow - https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest | ||
// Implicit Flow - https://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest | ||
// 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") { | ||
return errorsx.WithStack(ErrInvalidRequest.WithHint("The 'redirect_uri' parameter is required when using OpenID Connect 1.0.")) | ||
} | ||
|
||
// Validate redirect uri | ||
redirectURI, err := MatchRedirectURIWithClientRedirectURIs(rawRedirURI, request.Client) | ||
if err != nil { | ||
|
@@ -176,14 +187,18 @@ func (f *Fosite) validateAuthorizeRedirectURI(_ *http.Request, request *Authoriz | |
return nil | ||
} | ||
|
||
func (f *Fosite) parseAuthorizeScope(_ *http.Request, request *AuthorizeRequest) error { | ||
request.SetRequestedScopes(RemoveEmpty(strings.Split(request.Form.Get("scope"), " "))) | ||
|
||
return nil | ||
} | ||
|
||
func (f *Fosite) validateAuthorizeScope(ctx context.Context, _ *http.Request, request *AuthorizeRequest) error { | ||
scope := RemoveEmpty(strings.Split(request.Form.Get("scope"), " ")) | ||
for _, permission := range scope { | ||
for _, permission := range request.GetRequestedScopes() { | ||
if !f.Config.GetScopeStrategy(ctx)(request.Client.GetScopes(), permission) { | ||
return errorsx.WithStack(ErrInvalidScope.WithHintf("The OAuth 2.0 Client is not allowed to request scope '%s'.", permission)) | ||
} | ||
} | ||
request.SetRequestedScopes(scope) | ||
|
||
return nil | ||
} | ||
|
@@ -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 { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that instead of splitting |
||
return request, err | ||
} | ||
|
||
if err = f.validateAuthorizeRedirectURI(r, request); err != nil { | ||
return request, err | ||
} | ||
|
||
if err := f.validateAuthorizeScope(ctx, r, request); err != nil { | ||
if err = f.validateAuthorizeScope(ctx, r, request); err != nil { | ||
return request, err | ||
} | ||
|
||
if err := f.validateAuthorizeAudience(ctx, r, request); err != nil { | ||
if err = f.validateAuthorizeAudience(ctx, r, request); err != nil { | ||
return request, err | ||
} | ||
|
||
if len(request.Form.Get("registration")) > 0 { | ||
return request, errorsx.WithStack(ErrRegistrationNotSupported) | ||
} | ||
|
||
if err := f.validateResponseTypes(r, request); err != nil { | ||
if err = f.validateResponseTypes(r, request); err != nil { | ||
return request, err | ||
} | ||
|
||
if err := f.validateResponseMode(r, request); err != nil { | ||
if err = f.validateResponseMode(r, request); err != nil { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? |
||
return request, err | ||
} | ||
|
||
|
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 nowThere was a problem hiding this comment.
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!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.