What is the appropriate forum for OAuth/OpenIDConnect web server in a WebFarm question?

[Siegfried Heintze]

I have a question about creating a webapp (maybe springboot) that uses a common java based web servers like Tomcat or Jetty that Authenticates/Authorizes using OAuth/OpenIDConnect in a web farm environment (like a Kubernetes Replica set that has a auto scaler).


Background:

The microsoft documentation says: When Data Protection or caching isn't configured for a web farm environment, intermittent errors occur when requests are processed. This occurs because nodes don't share the same resources and user requests aren't always routed back to the same node.  A few paragraphs later they say

When any of the following symptoms occur intermittently, the problem is usually traced to improper Data Protection or caching configuration for a web farm environment:

Authentication breaks: The authentication cookie is misconfigured or can't be decrypted. OAuth (Facebook, Microsoft, Twitter) or OpenIdConnect logins fail with the error "Correlation failed."

Elsewhere they provide a list of magical caching plugins (not any cache will do ... I know this from hard experience) for C#/ASP.NET programmers that accommodate OpenIDConnect on web farms. Elsewhere they list the magical caching plugins to make your web app compatible with web farms and OpenIDConnect...

Question:
So my question is: Is the Microsoft documentation addressing problems specific to using ASP.NET with OpenIDConnect implementations on a web farm or is the need for magical caching plugins common to all web servers (like tomcast/jetty/nodejs) implementing OpenIDConnect in a web farm (like Kubernetes replica sets)? Again: I use the word magical here because not any  C#/ASP.NET redis cache (for example) will do the job.

In other words: if I deploy my springboot/tomcat webapp and use OAuth/OpenIDConnect to Authenticate/Authorize my users when the web app is running  with an autoscaler inside a kubernetes replica set, do I need to call some magical caching function? If so, were is the list of magical caching functions?

What is the appropriate forum to post this question in?

Thanks
Siegfried

[Stephan van Hulst]

The problem is not specific to ASP.NET Core, but the solution might be.

What solution is appropriate for your setup depends on how your application uses OAuth/OIC. Let's think about it for a second:

Lets say the client sends a bearer token with every request to your backend, and your backend uses the bearer token to perform actions on behalf of the user. Assuming that each node is stateless and uses the same database cluster, then you don't need to do anything at all because there is no cached state that needs to be shared between each application node.

However, if your application backend exchanges a client's authorization code for an access token and stores that access token in the user session on the server side, you need to replicate the user session among your application nodes. Tomcat has a guide on session replication. More hackery might be needed if each of your application nodes is seen as a separate entity by the authorization server.

As for caching, I'm not sure whether Java application containers provide built-in support for cache replication, but at least a quick Google search for "kubernetes tomcat cache" seems to come up with at least one third-party solution to this problem.

At any rate, my advice is to consider this as two separate problems:

1) What OAuth flow / grant type do you want to use, and how do you want to store the tokens associated with the user session?
2) How to replicate in-memory application state across application nodes?

[Siegfried Heintze]

Stephan van Hulst wrote:The problem is not specific to ASP.NET Core, but the solution might be.

What solution is appropriate for your setup depends on how your application uses OAuth/OIC. Let's think about it for a second:

Lets say the client sends a bearer token with every request to your backend, and your backend uses the bearer token to perform actions on behalf of the user. Assuming that each node is stateless and uses the same database cluster, then you don't need to do anything at all because there is no cached state that needs to be shared between each application node.

Thanks Stephan....

I've been re-reading the Microsoft Documentation (again) and thinking about your example... Your right: if one node in a replica-set gets a bearer token from a third party authentication service like AzureAD/B2C, then the shared cache should make that available to the other nodes should the load balancer route that user to a different member of the replica set so there is no problem: that new node has the bearer token too (because of the shared cache)! So I wonder if the problem is when you use the (optional) Microsoft ASP.NET data protection feature because you cannot trust your cache with unencrypted data like bearer tokens? Do web server caches typically store bearer tokens unencrypted? If so, then you might want store the bearer tokens as (double?) encrypted in the cache but then the web servers need to safely store some encryption keys someplace else (like the azure key vault) and this ability to store/retrieve encrypted bearer tokens from the cache might be the feature that makes some (but not all) ASP.NET/Kestrel caches magical....

So I guess that begs the question: Is Microsoft the only one in town that offers this data protection feature for web servers? Surely AWS and Google offer it... I wonder what they call it?

Here is what the ASP.NET Data Protection Documentation says:


The canonical example of this is an authentication cookie or bearer token. The server generates an "I am Groot and have xyz permissions" token and hands it to the client. At some future date the client will present that token back to the server, but the server needs some kind of assurance that the client hasn't forged the token. Thus the first requirement: authenticity (a.k.a. integrity, tamper-proofing).

Since the persisted state is trusted by the server, we anticipate that this state might contain information that's specific to the operating environment. This could be in the form of a file path, a permission, a handle or other indirect reference, or some other piece of server-specific data. Such information should generally not be disclosed to an untrusted client. Thus the second requirement: confidentiality.

I assume that "persisted state" means the cache.

This leads me to believe that the Microsoft ASP.NET web server (Kestrel) does not by default encrypt its caches... And I'm guessing that the Tomcat, Jetty, nodejs web servers don't encrypt their bearer tokens (when storing them in the shared cache) either because you don't typically specify a third party key store...

I thought the big feature with JWT and bearer tokens was that they were encrypted and could not be forged easily (because of signatures) and that may be true for transmission over socket connections...  But, lets suppose you store the encrypted JWT/Bearer token in your cache and the cache is not secure and someone gets the encrypted bearer token and sends it to the web server.... Oh oh! Data breach!

Hmmm... Comments?