[1.13] New OAuth2 middleware with token persistence

[ItalyPaleAle]

Fixes #2635
Replaces #2963 and #2964

Currently the OAuth 2 middleware suffers from scalability issues as reported in #2635. Tokens obtained from the authorization server are stored in-memory in the Dapr runtime (a session ID is stored in a cookie on the client), so they do not persist if the runtime is restarted, and make it impossible to scale the application horizontally.

The most common solution to this problem is to store the tokens in the clients, as self-contained tokens such as JWTs; because tokens are sensitive, they are encrypted (using encrypted JWTs).

This PR rewrites the OAuth2 middleware to allow for 2 different behaviors based on the new mode metadata property:

• cookie (default)
  • Just like today's component, stores the JWT in a cookie that is passed to the client.
  • After successfully authenticating, users are automatically redirected to the endpoint they were visiting at the beginning
• header:
  • Requires the token (issued by Dapr and not by the IdP!) to be present in the Authorization header
  • When users authenticate successfully, the client sees a response with a JSON body containing a single key Authorization and the value of the Authorization header that clients must pass
  • Note that there's no automatic redirect here

Why 2 modes?

The reason why we have two modes is due to the issue described in #2963. TLDR: tokens returned by Azure AD can be too large to be stored in a cookie.

However, using headers is not a perfect 1:1 replacement:

• Cookies can set in a 302 response while the client is redirected to the original endpoint that was invoked. We cannot do that with headers
• Cookies are handled automatically by browsers and other clients, while headers must always be handled manually

Token encryption key

Because cookies now store the token encrypted, users need to provide an encryption key via the new metadata property tokenEncryptionKey:

• This property is required.
• For backwards-compatibility, in Dapr 1.12 this property is optional and, if missing, a key will be randomly-generated by the runtime. When this happens, the key is ephemeral so tokens do not survive a restart of the Dapr runtime and horizontal scaling is not supported - this is pretty much what happens in Dapr 1.11 today! I have opted for allowing this behavior in Dapr 1.12 to offer a smoother transition period (even if the component is in alpha stage).
• Technically speaking, tokenEncryptionKey is not the actual encryption key used: the Dapr runtime deterministically derives both a signing key and an encryption key from that

Included in this PR

• Unit tests with a mocked IdP
• metadata.yaml

Future work

• When Allow (middleware) components to define internal actors dapr#6538 is implemented, we can use actors (if enabled) to store tokens when they're too large for a cookie. In this case, if the cookie is small enough, it's sent to the client as-is. Otherwise, Dapr stores the token in an actor's state, and then sends a session ID as cookie to the client; this is done transparently only for tokens that are too large to be included in cookies.
• Add certification tests so the component can be made stable. See Certification test for middleware.http.oauth2 #2621 .
  • Note that because this PR is essentially a complete rewrite, the components cannot be made stable until Dapr 1.13 at the earliest, even with certification tests
• The middleware middleware.http.oauth2clientcredentials has the same issues with scalability as the OAuth2, and needs to be updated as well (and perhaps we can re-use the shared implementation of this middleware).

[DeepanshuA]

Doing the very first pass. Will try to review it more thoroughly.

[DeepanshuA]

Should we change the name headerModeGetClaimsFromHeader to GetClaimsFromHeader, so that it is in sync with GetClaimsFromCookie ?

[DeepanshuA]

Suggested change

	m.setTokenFn = m.headerModeSetTokenResponse
	m.setTokenFn = m.headerModeSetTokenInResponse

or cookieModeSetTokenInResponse to cookieModeSetTokenResponse

[DeepanshuA]

Trying to understand: Why claims are always fetched from cookie and not from header, if code and state are provided?

[DeepanshuA]

Here, we rely on code being not blank to exchange it to get access token. Should we also check response_type somehow before doing so?
Ref: https://darutk.medium.com/diagrams-and-movies-of-all-the-oauth-2-0-flows-194f3c3ade85 and https://stackoverflow.com/a/74547318/18848251

[ItalyPaleAle]

I think we should push this to 1.13 for when internal actors for components (dapr/dapr#6538) is available. At this stage, it's highly unlikely internal actors for components are available in 1.12.

The reason is that in the current case, it fails when tokens are large, such as with Azure AD.

Although this PR does fix a very important issue, it may be a lesser issue than the alternative.

Thoughts? @dapr/maintainers-components-contrib

[berndverst]

I'm fine postponing this to 1.13. If so, do you want to mark it as a draft PR and add 1.13 to the title for now @ItalyPaleAle ?

[github-actions]

This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions!