release-20.2: auth: use HMAC to secure OIDC flow #56502
Merged
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.
Backport 1/1 commits from #55556.
/cc @cockroachdb/release
This change replaces existing server-side state validation logic
implemented for the OIDC flow with a stateless HMAC-based state
validation.
The goal is to ensure that we process requests that we initiated,
and also to bind the user's browser session to their auth request so
that one user can't process the callback for another user's auth request.
The HMAC-based method works as follows:
When the auth request is triggered, we generate 2 random byte arrays:
a secret key and a token. The secret key is stored in a browser cookie
at the client. The token is hashed using HMAC with the secret key and
the resulting hash and token pair are encoded into a protobuf and sent
along to the auth provider as the
state
param.When the auth callback is triggered, we receive back the same encoded
protobuf we sent over, containing the token and the HMAC hash. We then
retrieve the secret key in the client's browser cookie. Then the secret
key and token are used to reconstruct the expected hash and check it
against the one in the state protobuf we just decoded.
If the hash matches we proceed with authentication, if it does not we
immediately fail.
This change makes it possible to validate the state in the query param
against the browser cookie without any server-side state or
communication between CRDB nodes.
Since the OIDC feature is experimental, this change also removes the
state validation RPC calls and protos. A consequence of this is that a
cluster in the process of upgrading will experience malfunction of the
OIDC-based login flow if the node that initiated the auth flow and the
one that handles the callback are running different versions that use
different state validation logic.
This change is part of #54619
Release note (security update): This change modifies the state
validation for the OIDC login flow and replaces it with a stateless hash
validation of the state parameter with the browser cookie using HMAC.