When running ASP.Net Core 2.0 Web API endpoints which use JWT based authentication we always see the following error, despite not - as I understand matters - requiring Data Protection:
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35] No XML encryptor configured. Key {GUID} may be persisted to storage in unencrypted form.
Is there some way of preventing this warning? Will this cause us any issues?
Our system comprises of Web API HTTP endpoints running on Docker managed by Kubernetes with all JWTs issued by an authentication endpoint.
If you haven't configured DataProtection then (on Linux) it will persist keys in memory (ephemeral). The key will only be persisted until the application restarts - in most cases this won't cause a problem as they will continue to be created on-demand.
You may not be using DP for generating JWTs but it is used for a lot of other things too (generating tokens, for example).
Thanks for getting back to me. We are not using any cookies, OIDC or ASP.Net Identity, just Microsoft.AspNetCore.Authentication.JwtBearer & Microsoft.IdentityModel.Tokens with our own identity management system.
In light of this would you mind expanding on the following please:
You may not be using DP for generating JWTs but it is used for a lot of other things too (generating tokens, for example).
Without looking into your implementation I cannot tell you precisely where it is persisting information - but the exception message clearly shows that it persists a unique identifier.
IF login information is persisted by the app, then as long as it is using ephemeral storage users could find themselves with an expired token if the application restarts. That's about the only drawback I can think of.
To address this you should configure Data Protection to persist to a location on disk (ensuring the folder permissions are restrticted to the Apache user).
In addition, you should protect it with X.509 certificate which will prevent the warning.
Data Protection is also used by internal components, for example MVC uses it for CSRF tokens. Now if you're only using WebAPI with no CSRF because you're using the right authentication method, bearer tokens, you can safely ignore this.
Thank you both for your replies. I had read through all the available doco and gone through a lot of the source code trying to find a definitive answer and could not see why we would need the Data Protection; however, I did not want to make an assumption which later turned out to be incorrect,.
We are indeed only using WebAPI with bearer tokens.
Most helpful comment
Data Protection is also used by internal components, for example MVC uses it for CSRF tokens. Now if you're only using WebAPI with no CSRF because you're using the right authentication method, bearer tokens, you can safely ignore this.