title: Using Data Protection API as a key manager for JWT
body: <p>I'm using JWT as a container for access tokens, and want to add the rotation of the signing keys. I found that Data Protection API provides this functionality out-of-the-box.</p>
  <p>While DP API is the interface to (symmetric) encrypt/decrypt the data, JWT should be signed, so they are incompatible originally.</p>
  <p>Would it be secure to have such flow:</p>
  <ol>
  <li>JWT <code>kid</code> to store the Key Id from DP API</li>
  <li>DP API to auto-rotate keys based on the time policy</li>
  <li>JWT to use a custom <code>IssuerSigningKeyResolver</code> to retrieve the raw key from DP API by <code>kid</code> value</li>
  </ol>
  <p>That means that all existing/expired keys can be used to validate any token. To invalidate the token, the key can be revoked/deleted from DP API key ring.</p>
  <p>A custom invalidation logic for distributed applications: reload the keyring on token validation error, so the instance can get the most recent key that was generated by another instance.</p>
  <p>My concerns:</p>
  <ol>
  <li>Microsoft <a href="http://IssuerSigningKeyResolver" rel="nofollow noreferrer">does not recommend</a> using IKeyManager directly</li>
  </ol>
  <pre><code>Developers should very rarely (if ever) need to use the key management APIs directly
  </code></pre>
  <p>But I'm not sure where it is related to the key access rather than rotation management
  2. Exposing the key id within <code>kid</code> JWT header. I don't see a security issue here, but it does not mean there is no such
  3. There is no a simple way to access the key buffer</p>
  <p>Did anyone try to do something similar? Is there a simple strategy for the key rotation/management?</p>