Allow interactive login for accessing private ports of tasks

[psFried]

The goal is to make it so that users can just click a link for a private port and be taken through the authentication flow automatically. Here's the plan for how that can work:

• to begin, a user navigates to their task's URL, e.g. https://abc123-8080.dataplane.estuary-data.dev/
• DPG looks for a __Secure-flow_auth cookie, and allows using that to authenticate requests to private ports. Uses the same data-plane JWT we do today
• If the cookie is missing or if the JWT is expired, then DPG will redirect to dashboard.estuary.dev, passing the requested auth scope and a redirect url as query parameters.
  • Example: dashboard.estuary.dev/data-plane-auth-req?catalog_name=$taskName&redirect_to=${dataplane.estuary-data.dev/auth-redirect?orig_url=$originalUrl}
• We'll add the /data-plane-auth-req page to the UI, which requires the user to login to dashboard.estuary.dev and ultimately redirects back to DPG.
• On that UI page, a JS function will request a data-plane JWT with the scope of just that catalog_name
  • If successful, it navigates the user to dataplane.estuary-data.dev/auth-redirect?orig_url=$orig_url&token=$jwt
  • If the user is unauthorized, should we redirect with an error param or show an error directly on dashboard.estuary.dev?
• In DPG, we add an /auth-redirect handler that takes the token and orig_url and returns another redirect to the orig_url
  • The redirect has a Set-Cookie header, setting __Secure-flow_auth to the value of the token from the URL
  • The cookie is set with the Domain attribute set to the full subdomain of the specific task that they are accessing.
  • Note that the /auth-redirect handler uses the base data-plane hostname, not the hostname for the specific task.
  • The fact that the redirect location (the task-specific hostname) is a different origin means that the browser will stip the query params from the Referer header.
  • See the strict-origin-when-cross-origin section of the Referrer-Policy MDN page

[psFried]

As I got into the implementation, I realized there were a few things that needed to be changed.

• The Set-Cookie header needs to come from the specific domain of the task endpoint that the user is connecting to. Browsers don't allow you to set a cookie from domain.com with a Domain attribute of sub.domain.com. So the DPG /auth-redirect handler is now accessed under the endpoint-specific hostname, e.g. https://abc123-8080.dataplane.estuary-data.dev/auth-redirect. Of course a container could technically have its own /auth-redirect handler, so DPG only routes the request to its own handler if the request is unauthorized.
• Part of the reason for wanting the Set-Cookie to come from the main data-plane domain in the first place was to avoid the token url parameter from being sent as part of the Referer header. It turns out, the default Referrer-Policy of strict-origin-when-cross-origin already avoids this scenario. The Referer will only include the origin (not the path).
• Because we're using the task-specific hostname, the name of the cookie is now __Host-flow_auth, which tells the browser that the cookie must not have a Domain attribute. In other words the cookie is always scoped to a single endpoint.
• The

So the revised summary is:

• to begin, a user navigates to their task's URL, e.g. https://abc123-8080.dataplane.estuary-data.dev/foo.html
• DPG looks for a __Host-flow_auth cookie, and allows using that to authenticate requests to private ports. Uses the same data-plane JWT we do today
• If the cookie is missing or if the JWT is expired, then DPG will redirect to dashboard.estuary.dev, passing the requested auth scope and a redirect url as query parameters.
  • Example: dashboard.estuary.dev/data-plane-auth-req?prefix=$taskName&orig_url=https://abc123-8080.dataplane.estuary-data.dev/foo.html
• We'll add the /data-plane-auth-req page to the UI, which requires the user to login to dashboard.estuary.dev and ultimately redirects back to DPG.
  • On that UI page, a JS function will request a data-plane JWT with the scope of only that prefix.
  • It validates that the hostname of the $orig_url is a subdomain of the gateway_url that's associated with the given prefix. This is to prevent malicious links from sending the token to naughty servers.
  • If successful, it navigates the user to ${orig_url.host}/auth-redirect?orig_url=$orig_url&token=$jwt
  • If the user is unauthorized or there's any other error, then we just render the error without redirecting.
• In DPG, we add an /auth-redirect handler that takes the token and orig_url and returns another redirect to the orig_url
  • The redirect has a Set-Cookie header, setting __Host-flow_auth to the value of the token from the URL
  • DPG only routes requests to its own redirect handler when the incoming request is unauthorized.

[psFried]

estuary/ui#526 is a related UI PR, which implements the /data-plane-auth-req page, and also displays exposed endpoints in the UI so that users can find them easily.