I’m not sure this would qualify for ASP.NET Core Identity Auth or not because it’s a bit non-standard. We are looking to have a third party authentication server, where the auth is validated entirely by client side code, and the auth jwt is stored not in a cookie but in local storage (never mind if this is more or less secure than cookies, we’ve had that discussion and continue to have it, but I want to make sure I can support this local Storage setup).
So the third party JWT is going to come through each SS request in the header, and I need to validate the jwt and convert it to a SS session. The JWT payload has custom keys that I can use to validate, I’m just not sure if I can use the new ASP.NET Core Identity Auth stuff or if the original JwtAuthProviderReader is the best way to go.
From what I can tell from your description, you could potentially extend the NetCoreIdentityAuthProvider at the PreAuthenticateAsync method to perform your validation, and your own MapClaimsToSession equivalent. I think this would have the flexibility you need, but you would need to test it with your specific setup.
I am trying something slightly different than your suggestion and it appears to be working but it’s brought up another problem. I created ASP.Net Core Authentication middleware by subclassing AuthenticationHandler. It is very easy to create claims in that class’s HandleAuthenticateAsync method (which I would do by parsing the jwt in the request header), and then shortly afterwards the NetCoreIdentityAuthProvider maps all those claims to the SS session as I want.
The new issue that I have is that, in the absense of that jwt header, it’s difficult to test any of the services, say from a browser, or from integration tests. I have UI developers who run services from the browser all the time to see how the service data is going to look while they build the UI.
I tried implementing a CredentialsAuthProvider alongside the NetCoreIdentityAuthProvider, and that is working on its own, but when I issue any authenticated request, my custom auth middleware runs before SS can find the CredAuthProvider and 401s everything.
I’m wondering if I can detect within my auth middleware that the user is authenticated via the CredAuthProvider and pass the request along so that provider picks it up.
You’re not going to have access to ServiceStack’s Request Context from an ASP .NET Core Middleware but you should be able to check for the ss-id/ss-pid Session Cookie than look it up in your cache provider to find the users session using the Session Key Format: