How to swap authentication types

[divinebovine]

I'm writing a webapi service that enables a react frontend to authenticate users using cookies and session data. I would like to proxy requests to internal microservices swapping the authentication for bearer tokens. Can you provide a good sample for this?

[Tratcher]

Honestly we haven't designed that flow yet, we're waiting for feedback on what people need.

For your flow:
Step 1) Have you been through the auth docs to enforce cookie auth for the incoming requests?
Step 2) You would probobly write a proxy middleware to:

• take the authenticated user info, (e.g. HttpContext.AuthenticateAsync(scheme))
• generate a JWT, (IdentityModel?)
• and add it to the request, probably by directly setting the auth header.

As JWTs are signed, you also have the question for how to share those signing keys with the destination server.

[divinebovine]

@Tratcher thanks for the quick response.

Yes I've been reading through all of the docs and am in the process of testing it out. I was just hoping I've overlooked some samples somewhere.

I'm already generating JWT tokens and validating them with JWKS endpoint. I'll look into the middleware now and try to post something if I can get it working.

Thanks!

[divinebovine]

@Tratcher I was able to do just like the sample you linked me to, thanks so much!

app.UseEndpoints(endpoints =>
{
   endpoints.MapControllers();
   endpoints.MapReverseProxy(proxyPipeline =>
   {
   	proxyPipeline.Use(async (context, next) =>
   	{
   		var someCriteria = true;
   		if (someCriteria)
   		{
   			var sessionFeature = context.Features.Get<ISessionFeature>();
   			
   			// create token here using session store and any other sources for claims

   			context.Request.Headers.Add("Authorization", $"Bearer: {token}");
   		}
   		await next().ConfigureAwait(false);
   	});
   });
});

[divinebovine]

Noted, what are the concerns with storing user claims in session data and using those claims to construct a JWT?

[Tratcher]

Session lifetime isn't tied to users signing in, out or expiring. If they just leave the browser open then their login should expire soon, but their session won't.

[divinebovine]

Would it be better to just use a cookie to store a cache id and store claims in our distributed cache, much like session is doing? Wouldn't this bypass the session issues that you mentioned?

[Tratcher]

Why not use the built in cookie auth component?
https://github.com/dotnet/aspnetcore/blob/4ecde5f6b0d1aba59c7bd0646e20e7b16a78f767/src/Security/Authentication/Cookies/samples/CookieSample/Startup.cs

[divinebovine]

Largely the concern was the cookie size limitations, but in hindsight, I think that won't be an issue. Thanks for the feedback!

[macsux]

We've been using HTTP Headers to do Auth/Authz at the proxy and propagate identity downstream as HTTP headers. This implies there is implicit transport security between proxy and final destination provided by the infrastructure, but this is now increasingly common with SDN, K8S, and use of reverse proxies in sidecar scenarios. I believe this is also a model that is applied by Azure AppService (they auto inject HTTP module to reconstruct .NET Principal from authentication headers). Consider offering this out of the box as it greatly simplifies downstream services processing identity without having to deal with any security blocks. We've been using this to offload Kerberos validation to the sidecar. The identity is extracted and 2 headers are sent downstream:

X-Identity: someuser\domain
X-Roles: User,SomeGroup

Alternatively repackaging identity into JWT can provide greater flexibility as it allows for the much richer expression of principal than plaintext headers above. For this option, it would be useful to have the ability to send both signed and unsigned tokens. Unsigned JWT tokens would lessen the burden of dealing with managing JWK that proxy would need to expose and downstream having to configure.

Signed JWT should also be supported by exposing a JWK url at the proxy. This is to facilitate scenarios where security between proxy and destination cannot be enforced at the transport infrastructure level. Also, some JWT libraries don't support unsigned JWT tokens.

There's also the concept of identity delegation. Consider downstream service wanting to make further downstream calls on behalf of user. OAuth2 supports this via token-exchange where the original incoming token is exchanged to acquire extract claims that the downstream service is implicitly authorized for without requiring user consent. Kerberos also supports this by either delegating TGT of the user (unconstrained delegation) or via similarly constrained delegation which is very similar to oauth2. In all of these cases, there is a desire to propagate the original token/ticket downstream for further use.

[bnolan001]

If the architecture utilizes Backend for Frontend (BFF) then the change in code is minimal as compared to what @divinebovine already posted. Within the Startup.cs:Configure(IApplicationBuilder app) function modify your app.UseEndpoints call to pull the token out of the context and then add it to the context.Headers. According to the documentation all headers from the Request will be forwarded on to the proxied service.

           app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();
                endpoints.MapReverseProxy(proxyPipeline =>
                {
                    proxyPipeline.Use(async (context, next) =>
                    {
                        var token = await context.GetTokenAsync("access_token");
                        context.Request.Headers.Add("Authorization", $"Bearer {token}");
                        
                        await next().ConfigureAwait(false);
                    });
                });
            });

Thanks to @divinebovine for their post. It got me on the right track to figure this out.

[Tratcher]

Hey everyone, #703 has been completed and should help with this scenario. Check out the updated docs it includes and try changes in the daily builds.