We are looking to run .NET Web API projects as serverless applications hosted in AWS Lambda behind API Gateway [following an approach like this: https://aws.amazon.com/blogs/developer/deploy-an-existing-asp-net-core-web-api-to-aws-lambda/].
For applications that require authentication on the API with a JWT, we have been researching the methods for storing JWTs in local storage vs cookies in our front end SPAs that talk to the API.
It seems like one of the big caveats of using cookies for storing JWTs, specifically the AccessToken, is the potential for XSRF/CSRF attacks. With server side render apps, the use of anti-forgery tokens embedded in the html payload seems to help mitigate this risk. However with a SPA and our Web API running within Lambda - with each client request potentially being handled by any currently executing Lambda context (or a new one spun up if needed) this seems like it may be hard to achieve since there would be no persisted state between client request/response from the server.
It seems like generating an analogous temporary secret based on the scopes found in the user's access token might be a way to handle this in a stateless environment. However, with everything related to security, rolling your always seems like a terrible idea.
My question is if there are any known packages/libraries or approaches for this type of use case that can help mitigate CSRF/XSRF for .NET running in a distributed, serverless environment such as AWS Lambda. Or is the recommended approach to use local storage?