Do not use wildcard domains for cookies set by OAuth flow

MR:

• Update cookie to not use wildcard domain (gitlab-org/workspaces/gitlab-workspaces-proxy!34 - merged)
• Gracefully transition from old cookie to new co... (gitlab-org/workspaces/gitlab-workspaces-proxy!35 - merged)
• Update GitLab Workspaces Proxy version (!199422 - merged)
• Upgrade terraform lock file (gitlab-org/workspaces/examples/workspaces-infrastructure-setup-aws!1 - merged)
• Add variable for helm chart version of GitLab W... (gitlab-org/workspaces/examples/workspaces-infrastructure-setup-aws!2 - merged)

Description

Context - https://www.youtube.com/watch?v=yaduVqx8dTo&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=11 (At 16:40 minutes)

When user accesses a workspace, we first perform an OAuth redirect. This OAuth redirect sets a cookie. Right now, this cookie is set on the root domain i.e. if the workspace URL is WORKSPACE_NAME.test.com, the cookie is set on .test.com. This means the cookie is sharable across all workspaces. Furthermore, the cookie is accessible from the console since it is not secure.

We need to fix this.

Rollout Plan

• Create MR in https://gitlab.com/gitlab-org/workspaces/gitlab-workspaces-proxy .
• Create a new release.
• Update our infrastructre examples with the latest version if there are any references to the old versions - https://gitlab.com/gitlab-org/workspaces/examples/workspaces-infrastructure-setup-aws
• Update the docs for Helm chart installation of GitLab Workspaces Proxy - https://docs.gitlab.com/user/workspace/set_up_gitlab_agent_and_proxies/#install-the-gitlab-workspaces-proxy-helm-chart . In this MR, add a Changelog trailer so that it is visible in the changelog and users can take appropriate actions.
• Update internal DX team to update their cluster with the latest version.

Implementation details

GitLab Workspaces Proxy

1. User accesses ws1.workspaces.example.com.
2. Auth middleware detects there is no valid cookie or a transfer token in query param. It redirects to the OAuth provider - gitlab.example.com/oauth/authorize.
3. OAuth provider perform authentication and redirects back to workspaces.example.com/auth/callback.
4. OAuth redirect callback handler exchanges the code for token, gets the authenticated user from token, checks if user is authorized to access the workspace and redirects back to the original URL with an additional query param which contains the transfer JWT. This JWT is valid for a very short time(e.g. 30 seconds).
5. Auth middleware detects is no valid cookie but there is a transfer JWT in query param, it uses the query param value to read the JWT, check if it is valid, generate a new cookie JWT and set the cookie for the domain ws1.workspaces.example.com. It removes the query param from the request's URL and redirect back to the original URL with the cookie set.
6. Auth middleware detects a cookie, extracts the session from the cookie, validates the JWT in the cookie value and adds the user to the request context and serve the next middleware and return.

Workspaces HTTP Server

This will not be tackled as part of this issue. But the details have been discussed and finalized here as follows.

1. User accesses ws1.workspaces.example.com.
2. Auth middleware detects there is no valid cookie or a transfer token in query param. It redirects to the OAuth provider - gitlab.example.com/oauth/authorize.
3. OAuth provider perform authentication and redirects back to kas.example.com/workspaces/oauth/redirect.
4. OAuth redirect callback handler exchanges the code for token, gets the authenticated user from token, checks if user is authorized to access the workspace, stores the transfer session in transferTokens cache and then redirects back to the original URL with an additional query param which contains the transfer session id.
5. Auth middleware detects is no valid cookie but there is a transfer token in query param, it uses the query param value to look up session in the cache, delete it from the cache since it is meant to be single use, checks if the transfer session is valid, checks if the transfer session's host and the request's host match, generate a new user session and store it in the userSession cache and set the cookie for the domain ws1.workspaces.example.com. It removes the query param from the request's URL and redirect back to the original URL with the cookie set.
6. Auth middleware detects a cookie, extracts the session from the cookie, validates the session in userSession cache and adds the user to the request context and serve the next middleware and return.