-
-
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: requested scope ignored in refresh flow #718
base: master
Are you sure you want to change the base?
Changes from all commits
37a00cf
5d4da29
c5c6056
deb3be3
6db02e8
c472cd8
9a0bc79
45ede8b
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 |
---|---|---|
|
@@ -10,7 +10,6 @@ import ( | |
"time" | ||
|
||
"github.com/ory/x/errorsx" | ||
|
||
"github.com/pkg/errors" | ||
|
||
"github.com/ory/fosite" | ||
|
@@ -30,6 +29,11 @@ type RefreshTokenGrantHandler struct { | |
fosite.AudienceStrategyProvider | ||
fosite.RefreshTokenScopesProvider | ||
} | ||
|
||
// IgnoreRequestedScopeNotInOriginalGrant determines the action to take when the requested scopes in the refresh | ||
// flow were not originally granted. If false which is the default the handler will automatically return an error. | ||
// If true the handler will filter out / ignore the scopes which were not originally granted. | ||
IgnoreRequestedScopeNotInOriginalGrant bool | ||
} | ||
|
||
// HandleTokenEndpointRequest implements https://tools.ietf.org/html/rfc6749#section-6 | ||
|
@@ -69,7 +73,6 @@ func (c *RefreshTokenGrantHandler) HandleTokenEndpointRequest(ctx context.Contex | |
scopeNames := strings.Join(c.Config.GetRefreshTokenScopes(ctx), " or ") | ||
hint := fmt.Sprintf("The OAuth 2.0 Client was not granted scope %s and may thus not perform the 'refresh_token' authorization grant.", scopeNames) | ||
return errorsx.WithStack(fosite.ErrScopeNotGranted.WithHint(hint)) | ||
|
||
} | ||
|
||
// The authorization server MUST ... and ensure that the refresh token was issued to the authenticated client | ||
|
@@ -79,13 +82,50 @@ func (c *RefreshTokenGrantHandler) HandleTokenEndpointRequest(ctx context.Contex | |
|
||
request.SetID(originalRequest.GetID()) | ||
request.SetSession(originalRequest.GetSession().Clone()) | ||
request.SetRequestedScopes(originalRequest.GetRequestedScopes()) | ||
|
||
/* | ||
There are two key points in the following spec section this addresses: | ||
1. If omitted the scope param should be treated as the same as the scope originally granted by the resource owner. | ||
2. The REQUESTED scope MUST NOT include any scope not originally granted. | ||
|
||
scope | ||
OPTIONAL. The scope of the access request as described by Section 3.3. The requested scope MUST NOT | ||
include any scope not originally granted by the resource owner, and if omitted is treated as equal to | ||
the scope originally granted by the resource owner. | ||
|
||
See https://www.rfc-editor.org/rfc/rfc6749#section-6 | ||
*/ | ||
|
||
// Addresses point 1 of the text in RFC6749 Section 6. | ||
if len(request.GetRequestedScopes()) == 0 { | ||
request.SetRequestedScopes(originalRequest.GetGrantedScopes()) | ||
} | ||
|
||
request.SetRequestedAudience(originalRequest.GetRequestedAudience()) | ||
|
||
for _, scope := range originalRequest.GetGrantedScopes() { | ||
if !c.Config.GetScopeStrategy(ctx)(request.GetClient().GetScopes(), scope) { | ||
strategy := c.Config.GetScopeStrategy(ctx) | ||
originalScopes := originalRequest.GetGrantedScopes() | ||
|
||
for _, scope := range request.GetRequestedScopes() { | ||
// Utilizing the fosite.ScopeStrategy from the configuration here could be a mistake in some scenarios. | ||
// The client could under certain circumstances be able to escape their originally granted scopes with carefully | ||
// crafted requests and/or a custom scope strategy has not been implemented with this specific scenario in mind. | ||
// This should always be an exact comparison for these reasons. | ||
if !originalScopes.Has(scope) { | ||
if c.IgnoreRequestedScopeNotInOriginalGrant { | ||
// Skips addressing point 2 of the text in RFC6749 Section 6 and instead just prevents the scope | ||
// requested from being granted. | ||
continue | ||
} else { | ||
// Addresses point 2 of the text in RFC6749 Section 6. | ||
return errorsx.WithStack(fosite.ErrInvalidScope.WithHintf("The requested scope '%s' was not originally granted by the resource owner.", scope)) | ||
} | ||
Comment on lines
+115
to
+122
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. Side note when looking at this. I have a per-client implementation of this utilizing an interface which passes the same tests. Maybe this is more desirable? 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. What would be the use case of having this per-client? 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. The only way I'll personally use it is per-client where the default is to enforce the spec and you make an exception on a per-client basis. I'm happy enough to maintain my own entire implementation however. |
||
} | ||
|
||
if !strategy(request.GetClient().GetScopes(), scope) { | ||
return errorsx.WithStack(fosite.ErrInvalidScope.WithHintf("The OAuth 2.0 Client is not allowed to request scope '%s'.", scope)) | ||
} | ||
|
||
request.GrantScope(scope) | ||
} | ||
|
||
|
@@ -134,26 +174,36 @@ func (c *RefreshTokenGrantHandler) PopulateTokenEndpointResponse(ctx context.Con | |
err = c.handleRefreshTokenEndpointStorageError(ctx, err) | ||
}() | ||
|
||
ts, err := c.TokenRevocationStorage.GetRefreshTokenSession(ctx, signature, nil) | ||
originalRequest, err := c.TokenRevocationStorage.GetRefreshTokenSession(ctx, signature, nil) | ||
if err != nil { | ||
return err | ||
} else if err := c.TokenRevocationStorage.RevokeAccessToken(ctx, ts.GetID()); err != nil { | ||
} else if err := c.TokenRevocationStorage.RevokeAccessToken(ctx, originalRequest.GetID()); err != nil { | ||
return err | ||
} | ||
|
||
if err := c.TokenRevocationStorage.RevokeRefreshTokenMaybeGracePeriod(ctx, ts.GetID(), signature); err != nil { | ||
if err := c.TokenRevocationStorage.RevokeRefreshTokenMaybeGracePeriod(ctx, originalRequest.GetID(), signature); err != nil { | ||
return err | ||
} | ||
|
||
storeReq := requester.Sanitize([]string{}) | ||
storeReq.SetID(ts.GetID()) | ||
storeReq.SetID(originalRequest.GetID()) | ||
|
||
if err = c.TokenRevocationStorage.CreateAccessTokenSession(ctx, accessSignature, storeReq); err != nil { | ||
return err | ||
} | ||
|
||
if err = c.TokenRevocationStorage.CreateRefreshTokenSession(ctx, refreshSignature, storeReq); err != nil { | ||
return err | ||
if rtRequest, ok := requester.(fosite.RefreshTokenAccessRequester); ok { | ||
rtStoreReq := rtRequest.SanitizeRestoreRefreshTokenOriginalRequester(originalRequest) | ||
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. What is this change about? Why it is necessary? 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. Because the scopes of the current request are for the access token, not the refresh token. The scopes of the original granted refresh token must be restored to make it possible to meet the strict requirements of the spec:
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. No, I mean, my question is why you have two cases here. It looks like you added Also, I am not sure that an extra method is already needed here?
So why not just call Probably I am missing something, I just checked very quickly this. 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. An AccessRequester doesn't have SetGranted* receivers as part of the implementation. So a new receiver will be needed regardless. The question is just about what solution is going to lead to the least harmful outcome. Adding those receivers to the AccessRequester interface seems like a poor choice as it isn't used now but could potentially lead to implementers making harmful decisions in this stage of the relevant flows in my opinion. As far as the other I brought it up with aeneasr I believe so really up to an ory preference (he may have actually asked for it but I don't recall specifics). I personally don't have one myself in either direction. 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. It has 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 see the same being done currently in the code:
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 see this was a previous comment here: #718 (comment) 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. So to seems there is already some code to clone a requester. Maybe that should be just moved out into utility function and reused here for refresh token as well? (And again sorry if I am missing something.) |
||
|
||
rtStoreReq.SetSession(requester.GetSession().Clone()) | ||
|
||
if err = c.TokenRevocationStorage.CreateRefreshTokenSession(ctx, refreshSignature, rtStoreReq); err != nil { | ||
return err | ||
} | ||
} else { | ||
if err = c.TokenRevocationStorage.CreateRefreshTokenSession(ctx, refreshSignature, storeReq); err != nil { | ||
return err | ||
} | ||
} | ||
|
||
responder.SetAccessToken(accessToken) | ||
|
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.
Side note when looking at this. I have a per-client implementation of this utilizing an interface which passes the same tests. Maybe this is more desirable?
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.
Why is this not made through a new config interface?
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.
To me it looks like currently all config is done through config interface, even if it is not meant for hot reloading?