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

feat: remove flow cookie #3639

Merged
merged 5 commits into from
Oct 16, 2023
Merged

feat: remove flow cookie #3639

merged 5 commits into from
Oct 16, 2023

Conversation

hperl
Copy link
Contributor

@hperl hperl commented Sep 29, 2023

This patch removes the flow cookie. All information is already tracked in the request query parameters as part of the {login|consent}_{challenge|verifier}.

Related issue(s)

Checklist

  • I have read the contributing guidelines.
  • I have referenced an issue containing the design document if my change
    introduces a new feature.
  • I am following the
    contributing code guidelines.
  • 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 the 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 or changed the documentation.

Further Comments

@hperl hperl requested a review from aeneasr as a code owner September 29, 2023 12:34
@hperl hperl requested a review from alnr September 29, 2023 12:34
@hperl hperl self-assigned this Sep 29, 2023
@codecov
Copy link

codecov bot commented Sep 29, 2023

Codecov Report

Merging #3639 (1a65ee3) into master (a0c06ec) will increase coverage by 0.06%.
The diff coverage is 97.43%.

❗ Current head 1a65ee3 differs from pull request most recent head 606c405. Consider uploading reports for the commit 606c405 to get more accurate results

@@            Coverage Diff             @@
##           master    #3639      +/-   ##
==========================================
+ Coverage   76.10%   76.17%   +0.06%     
==========================================
  Files         132      132              
  Lines       10076    10030      -46     
==========================================
- Hits         7668     7640      -28     
+ Misses       1881     1874       -7     
+ Partials      527      516      -11     
Files Coverage Δ
consent/manager.go 100.00% <ø> (ø)
consent/manager_test_helpers.go 98.11% <100.00%> (-0.01%) ⬇️
oauth2/flowctx/cookies.go 100.00% <ø> (ø)
oauth2/flowctx/encoding.go 76.00% <ø> (-4.33%) ⬇️
persistence/sql/persister_consent.go 84.96% <100.00%> (+0.66%) ⬆️
consent/strategy_default.go 70.47% <92.30%> (+1.56%) ⬆️

... and 1 file with indirect coverage changes

alnr
alnr previously approved these changes Sep 29, 2023
Copy link
Contributor

@alnr alnr left a comment

Choose a reason for hiding this comment

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

It's beautiful.

loginChallenge = x.Must(f.ToLoginChallenge(ctx, deps))
got1, err = m.GetLoginRequest(ctx, loginChallenge)
require.NoError(t, err)
assert.True(t, got1.WasHandled)
Copy link
Member

Choose a reason for hiding this comment

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

Should this assertion not still be here? The flow was handled so it should be true right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Previously we persisted the flow in the database, so VerifyAndInvalidateLoginRequest set WasHandled to true in the DB. Since we now store the flow in the login verifier, there is no place to store information about whether the flow was already handled.

This is already true even without this patch.

If we want double-submit protection, we should build a separate NonceService (new creates a new nonce, use uses a nonce once) to make sure that the verifiers are only used once.

Copy link
Member

Choose a reason for hiding this comment

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

I see - do we protect against double submit for the consent verifier? Or can I generate as many authorization codes as I want with the same consent verifier?

Can I log in as often as I want to using the same login verifier?

Copy link
Contributor Author

@hperl hperl Oct 11, 2023

Choose a reason for hiding this comment

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

You can log in as often as you want, but the double-submit will be caught at the consent verification step.

I added a test case for consent verifier double submit here: f482f4e

// Trying to update this again should return an error because the consent request was used.
h.GrantedAudience = sqlxx.StringSliceJSONFormat{"new-audience", "new-audience-2"}
_, err = m.HandleConsentRequest(ctx, f, h)
require.Error(t, err)
Copy link
Member

Choose a reason for hiding this comment

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

Why is it ok to remove this assertion?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because we can't detect double submit any more.

consent/strategy_default.go Show resolved Hide resolved
consent/strategy_default.go Outdated Show resolved Hide resolved
updatedFlow.LoginCSRF = f.LoginCSRF
updatedFlow.LoginVerifier = f.LoginVerifier
*f = *updatedFlow

Copy link
Member

Choose a reason for hiding this comment

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

Could you briefly explain why we needed this in the first place so I better understand the reason why it's ok to remove this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Previously, we merged two flows here: The one decoded from the login verifier (verifier param), and the one from the cookie (f param). The code above ensured that these two flows are the same, so that the same flow information ends up in the cookie agan as well as in the consent challenge.

After removing the cookie flow, we do not have to do this any more.

@aeneasr aeneasr self-requested a review October 5, 2023 09:34
Copy link
Member

@aeneasr aeneasr left a comment

Choose a reason for hiding this comment

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

See above

@hperl
Copy link
Contributor Author

hperl commented Oct 12, 2023

@aeneasr what is still needed here?

@aeneasr
Copy link
Member

aeneasr commented Oct 13, 2023

  • Handle 500s on reuse gracefully

@aeneasr aeneasr merged commit cde3a30 into master Oct 16, 2023
29 checks passed
@aeneasr aeneasr deleted the hperl/flowcookieless-flow branch October 16, 2023 14:21
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.

3 participants