Use with JWT

[angtianqiang]

If the project has multiple sides, JWT is a better authentication method. Is there any event or interface related to the HTTP interface of CSLA? Before processing the service invocation of the server, JWT-related requests should be made, such as determining whether the TOKEN should expire and refreshing to obtain the latest TOKEN in time? There is a related DEMO for reference no.

[TheCakeMonster]

No, I don't think we have a demo of using JWTs as part of CSLA at the moment. Creating a demo is a bit problematic for reasons I will come to, and not entirely relevant.

CSLA tries not to involve itself with authentication, wherever possible. Instead, it delegates that responsibility to the platform, as far as it can. Using JWTs with CSLA should be exactly the same as using it with any other client/server pair of the technologies you are using. That's why I say it's not entirely relevant. It's not completely irrelevant, but the point is that it doesn't really have anything to do with CSLA.

There are a couple of sticking point when it comes to creating a demo of this usage:

1. Ideally demos should be standalone, but generating JWTs isn't entirely a standalone operation.
2. Demos need to be simple enough to be useful, and in my experience there is a LOT of nuance about configuring auth providers for JWT. It's not particularly difficult to do, but it is noisy in terms of code, and easy to get wrong.
3. The configuration code varies a bit by auth provider.

This may not seem like a good start to helping you, but it's relevant I explain why such a demo doesn't exist - yet. Adding one was discussed on the Discord channel recently, and someone offered to add one if they get time, so hopefully there will be one in the future.

Now let me try to help explain how a system using JWTs will work. You haven't given much detail of the version of .NET you are intending to use, so I will assume that it is .NET 6 in this answer. If that's not the case then the answer may be wrong.

It looks like you are talking about using the HTTP remote data portal. On the server side in ASP.NET Core, there is built in support for JWTs. The implementation is achieved using middleware. Enabling this is a case of configuring auth to support the particular auth provider you want to use. Sadly that varies a little bit by provider, but Google an example of the one you are interested in.

On the client side, you need to add the JWT to each request, and I think that might be what you are asking about. CSLA uses HttpClient under the covers for the HTTP remote data portal [there is a caveat later.] HttpClient requests can be intercepted using custom message handlers. This is the client-side equivalent of middleware. Again, this is a generic solution for all use of JWTs over HTTP, and the use of CSLA doesn't change how it is done. Any code you can find as an example should work. Here's an overview doc, but there are plenty of other samples out there.

https://docs.microsoft.com/en-us/aspnet/web-api/overview/advanced/httpclient-message-handlers

The caveat is relevant to client code; be careful of this. HttpClient only offers async methods - it's an intentional limitation of the implementation that Microsoft built for .NET Core. That means you HAVE to use async method calls from the client for HttpClient to be used. If you use synchronous data access method calls then CSLA falls back to using WebClient, and that doesn't respect message handlers as far as I know.

In short, you need to use IDataPortal.CreateAsync, IDataPortal.FetchAsync, and SaveAsync on your business object on the client. If you do that, the request is achieved using HttpClient, and the message handler will enable interception to add the JWT.

[Merfie]

Where would I create the custom message handlers to intercept the CSLA http requests? I have tried to set them up as I normally do but it doesn't look like they are intercepting the CLSA requests.

[rockfordlhotka]

There's nothing special about the controller used to create the aspnetcore endpoint for the data portal. It should work like any other API endpoint controller in terms of middleware.

You can, of course, override any methods in the controller implementation itself, but that shouldn't be necessary for this, as the middleware would run before the controller is even loaded right?

[Merfie]

I mean on client side. How would I add a header to the http request before it going to the server?

[rockfordlhotka]

I think this is something we can improve on, but right now instead of calling AddHtppProxy in your startup code, use this:

      var proxyOptions = new Csla.Channels.Http.HttpProxyOptions();
      // set any options here
      config.Services.AddTransient(typeof(IDataPortalProxy),
        sp =>
        {
          var applicationContext = sp.GetRequiredService<ApplicationContext>();
          var client = sp.GetRequiredService<HttpClient>();
          // configure client here
          return new Csla.Channels.Http.HttpProxy(applicationContext, client, proxyOptions);
        });

Because it is your code creating the HttpClient instance each time, you have access to that object and can do things like set the headers.

I suspect what we should do is have an action you can provide to AddHttpProxy to set headers.

[Merfie]

Thanks, that did the trick

[angtianqiang]

Thank you very much for the detailed explanation, you totally guessed my idea, there is no problem putting JWT TOKEN into HttpClient request header, I focus on how to intercept the request and request the latest TOKEN from the server before the service is cleared, if the TOKEN is about to expire.

[TheCakeMonster]

In all of the JWT implementations I can immediately think of, I would expect the client to be responsible for initiating the token refresh, not the server. Even if the server had to be involved in doing the refresh, I would create a dedicated endpoint on the server that the client can call to request that the refresh be performed. That way, the response from that dedicated server endpoint can be the refreshed token - it's a simple way to get the replacement token to the client.

Anyway, whether the refresh is initiated by the client or the server, the answer largely remains the same. To initiate on the client, you would look to use a custom message handler. To do initiate the refresh on the server, custom middleware in the request pipeline is probably an attractive option.

If you needed to scope the auth and its refresh solely to CSLA requests, you could override the method on the CSLA controller to which requests are sent. That's perfectly possible - but it seems unnecessarily limiting. Middleware will generally be a better option, in my opinion.