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.
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
Process OIDC code query param only if the state cookie exists #23274
Process OIDC code query param only if the state cookie exists #23274
Changes from all commits
844b978
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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'm also not 100% sure how reliable is this. Is it really needed?
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.
@pedroigor Good point, I've been contemplating above about it, it is the best effort at trying to figure out how to fail the request best if the state cookie is missing.
On the
main
it is an immediate 401. But on themain
it is also the problem that if thecode
is detected then it is assumed it is the redirect from KC - and only then then the state cookie is checked, but with theerror
and the Apple'sform_post
response mode to be supported next it just does not work - especially withform_post
- we can't start checking the post data without asserting the state cookie exists, so this refactoring is making these checks dependent on the availability of the state cookie.So now, if the state cookie is missing and 1) If no
code
is there - we fail indirectly by challenging the user with a redirect to KC - this is how it works onmain
2) ifcode
is there - we checkReferer
and if proved it comes from KC only then do we stop everything with 401 - this is new to this PR, instead of just failing with401
So if the
Referer
check fails then instead of 401 the user will be redirected to KC to re-authenticate. And as I said above, we can follow up with adding the property configuring what to do if the state cookie is missing and thecode
(error
) (query or form post) present - do 401 or redirect to KC. In fact I started with the property first but then thought it was unnecessary yet.Does it clarify it ?
We have a test expecting 401 in case of a missing state cookie and this code properly gives 401 as expected.
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 see. I'm still trying to figure out if this has some security implication because the header can be easily forged into the request. But don't think there is and it should improve UX.
Makes sense?
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.
@pedroigor Hi Pedro,
I'm not sure I follow, can you clarify please ?
This header is only checked in the
getChallenge
method. We don't do any positive decision based on its match - we only check it to decide how to fail ifstate cookie is not available but 'code' is
.If it matches the Keycloak authorization URL then it is 401 (meaning the authentication has failed, no retries), if it does not match it - it is a new unauthenticated request, the user goes to Keycloak/etc. This referer won't be used to redirect the user.
We can totally drop this check, but that will mean it will always be only a redirect to Keycloak
if the state cookie is absent but the code is there
; the referer check gives us an option to react to this case in a more nuanced way.It is really about this use case,
how to fail when the code is available but the state cookie is not
.I'm not sure, may be I will just drop this Referer check. We have a test where a state cookie is missing but the code is, and 401 is expected. Without this check I'll have to tweak the test to expect
302
to Keycloak in this case though.