Fix bug which prevents the at_hash
claim from appearing in the ID token from an authcode grant for some storage implementations
#679
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fosite has a bug which may prevent the
at_hash
claim from appearing in the ID token from an authcode grant. The bug is in thePopulateTokenEndpointResponse
method ofOpenIDConnectExplicitHandler
. The bug will only impact systems which implement the storage interfaces by returning different struct instances.There are two sessions at play the
PopulateTokenEndpointResponse
method ofOpenIDConnectExplicitHandler
:requester
parameter contains a session. In typical usage of fosite,requester
is created by a custom implementation of the token endpoint to represent the current request to the token endpoint. The token endpoint callsNewAccessRequest
, which callsHandleTokenEndpointRequest
on each token endpoint handler. TheAuthorizeExplicitGrantHandler
’s implementation of that function performs a storage lookup usingc.CoreStorage.GetAuthorizeCodeSession(ctx, signature, request.GetSession())
to find the authorize request for the given authcode. It then sets that session from storage onto the new request usingrequest.SetSession(authorizeRequest.GetSession())
(see flow_authorize_code_token.go).PopulateTokenEndpointResponse
method by callingc.OpenIDConnectRequestStorage.GetOpenIDConnectSession(ctx, requester.GetRequestForm().Get("code"), requester)
.These two sessions may not necessarily be the same instance (same pointer), depending on the implementation of the storage interfaces. Fosite should not assume that they will be the same instance, since they came from different calls to storage interfaces.
The last line of the
PopulateTokenEndpointResponse
method ofOpenIDConnectExplicitHandler
uses theauthorize
variable to create the ID token. The access token hash which is computed a few lines above must be set onto theauthorize
variable’s session in order to have it available during the creation of the ID token. The fix is to simply use theauthorize
variable’s session.Note that the bug did not impact the refresh grant, where the ID token does correctly include the
at_hash
claim.The unit tests in
flow_explicit_token_test.go
have been updated to use two different instances of sessions to demonstrate the issue. They have also been updated to be able to run independently without polluting each other, by moving the test setup into the loop and by having each test perform its own test setup. Before the fix, many of these tests fail when run individually because they were accidentally relying on the pollution caused by each previous test in the same file. A new test case was also added to backfill for a case (unrelated to the bug) which was not previously covered.The integration tests were not changed. They do not catch the bug because they use the storage implementation in
memory.go
which always returns the same session instance for the two relevant sessions. It might be nice if this storage implementation always returned a copy of the session (always different instances) but it is not obvious how to enhance the code in this way.Note that the unit and integration tests of the Pinniped project demonstrate the bug. Pinniped uses fosite to implement a partial OIDC provider which supports the OIDC authcode and refresh flows. The ID tokens returned by the authcode grant never includes the
at_hash
claim, but the ID tokens returned by the refresh grant do include the claim. The changes that would be made to the project’s tests if this bug fix is accepted into fosite are shown in Pinniped PR 1165. The Pinniped project has a unit test which performs an authcode grant and then performs a refresh grant, and the behavior of the fosite library can easily be observed by adding breakpoints in the relevant fosite code and then running the test in the debugger.Related Issue or Design Document
None.
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got green light (please contact [email protected]) from the maintainers to push the changes.
Further comments
None.