Openiddict-core: Question: Refresh token expiration upon deployment
I'm trying to figure out what causes our refresh token to be invalidated when we deploy new code. Is it something I can configure, or is it cased by our building pipeline (in Azure), where we first deploy to a staging server and then swap staging with production. We are using a signing certificate and json web tokens. Do something here use e.g. random numbers that is replaced during our swap?
Locally, the refresh token stays valid upon each build of the application, so that tells me it could be related to the staging/production servers. Of course, the real issue here is that users of the app need to re-login each time we deploy, so this is something I would like to avoid.
pb123456
>All comments
OpenIddict uses the rock-solid ASP.NET Core Data Protection stack to encrypt/HMAC its authorization codes and refresh tokens (certificates are only used to sign identity tokens... and access tokens if you opt for JWT access tokens).
If you haven't configured DP to use an explicit storage location, it will persist its master keys on the local disk. On Azure App Service, this storage method - that uses a virtual file system under the hood - is persistent so keys usually survive to reboots. The thing is storage is never shared between slots, which means keys generated on a staging server can't be used on a production server.
Security-wise, it's certainly an excellent thing. If you find it inconvenient, you can opt for storing the DP keys in a shared Azure Blob Storage location.
https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers?view=aspnetcore-2.2&tabs=visual-studio#azure-and-redis should put you on the right track if you need additional guidance.
kevinchalet
on 5 Feb 2019
Related issues
geocine
路
5Comments
AlphaCreativeDev
路
3Comments
Belaroth
路
4Comments
Typiqally
路
4Comments
ivanmariychuk
路
6Comments
Most helpful comment
OpenIddict uses the rock-solid ASP.NET Core Data Protection stack to encrypt/HMAC its authorization codes and refresh tokens (certificates are only used to sign identity tokens... and access tokens if you opt for JWT access tokens).
If you haven't configured DP to use an explicit storage location, it will persist its master keys on the local disk. On Azure App Service, this storage method - that uses a virtual file system under the hood - is persistent so keys usually survive to reboots. The thing is storage is never shared between slots, which means keys generated on a staging server can't be used on a production server.
Security-wise, it's certainly an excellent thing. If you find it inconvenient, you can opt for storing the DP keys in a shared Azure Blob Storage location.
https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers?view=aspnetcore-2.2&tabs=visual-studio#azure-and-redis should put you on the right track if you need additional guidance.