Mark Hughes

Indeed - this worry (regarding what happens when the DPAPI rolls the keys over) is why I haven't merged this pull request in yet, I want to know the answer...

Indeed... it might "just work", in that if it's configured correctly, it might be the case that the old expired keys are ALWAYS available for unprotect operations. But I read...

I've just had another look at the documentation, it has been updated since I last looked - [it now reads](https://docs.asp.net/en/latest/security/data-protection/consumer-apis/dangerous-unprotect.html): > ... there is nothing prohibiting a developer from using...

It feels like there's still an extra hop than should be needed. It would be ideal to use the DPAPI directly to sign and verify the tokens, thus removing the...

Hi @Icestorm0141 - from [the DP API documentation](http://aspnet.readthedocs.io/en/latest/security/data-protection/implementation/key-storage-providers.html#file-system) you can choose to store the keys on a UNC path accessible by all machines which need them. The DPAPI then manages...

I've not had the need to implement it yet, but the basic concept is you generate a long-lived token which can _only_ be used to request new tokens, **not for...

Thanks, looks great! I'll pull this down and check it out tomorrow.

Interesting! I have been trying something similar out in [this branch](https://github.com/mrsheepuk/ASPNETSelfCreatedTokenAuthExample/tree/UseCryptoProvider) but yours is a much more straightforward way of reaching the same result. I'll have a look and see...

Yes absolutely @bragma - which is why the strategy used in this pull request (or my branch) would work if used on a single machine, or used in a situation...

@bragma I've just noticed that, specifically in the case of Azure, the default DPAPI configuration should handle this so this may well "just work" - see [the docs for the...