[dotnet user-jwts] Move signing key details to top-level property

[captainsafia]

This PR changes the schema for storing signing keys for the user-jwts tool in user secrets to support more modifications in the future. Currently, the signing key is stored in a schema that looks like this:

{
  "Authentication": {
    "Schemes": {
      "Bearer": {
         "dotnet-user-jwts": {
            "KeyMaterial": "somesigningkeyhere"
        }
      }
    }
  }
}

Where the key is stored relative to the issuer and the scheme name. The new format is as follows:

{
  "Authentication": {
    "Schemes": {
      "Bearer": {
         "SigningKey": {
            "Value": "somesigningkeyhere",
            "KeyLength": 32
        }
      }
    }
  }
}

The Issuer is not a top-level unique identifier (only the schemes are) so it doesn't make sense to nest the key under this. The top-level SigningKey property gives us a place to add more options in the future (key algo and key modifications for key length).

[BrennanConroy]

Add test coverage for the value and length properties

[BrennanConroy]

Are multiple keys per issuer allowed?

[captainsafia]

It's possible for a single issuer/authorization server to produce a set of signing keys that the application can use with no preference between them (ref). Most of what I've seen about this touches on them being used for OIDC scenarios, but it helps to support it in some way with JWT since we want the local dev scenario to map nicely to the pod scenario.

[BrennanConroy]

What's the id for?

[captainsafia]

This is a little bit of a premature optimization. One of the things we discussed was making the key generation more robust in the future (supporting setting different key lengths, support different key types, crpyto algos, etc.). I included an ID field so it'll be easier to unique identifying signing keys in the future.

[BrennanConroy]

New format:

{
  "Authentication": {
    "Schemes": {
      "Bearer": {
        "SigningKeys": [
          {
            "Id": "FI9W0",
            "Issuer": "dotnet-user-jwts",
            "Value": "somesigningkeyhere",
            "KeyLength": 32
          }
        ]
      }
    }
  }
}

[BrennanConroy]

Ok, so if multiple keys for the same issuer is allowed, does reset need to delete all keys from the same issuer now?

[captainsafia]

So, to start, I'd only added support for multiple keys for the same issuer in the runtime, but not in the user-jwts tool. My rationale for this was that we would keep the surface area of the tool simpler than what the runtime could support. Users would still be able to support the multiple-keys-per-issuer if they set it up in config themselves, but the tool wouldn't support it.

I realize the incongruency is kinda weird though so maybe we should stick to one-key-per-issuer to keep things simple throughout the board (I want to avoid modifying too much of the existing handling in an RC1 PR).

[BrennanConroy]

I realize the incongruency is kinda weird though

Yeah, it's strange 😌, unless we have a scenario for multiple keys in the Runtime I don't feel like we should add it yet until both areas are updated.

[DamianEdwards]

I've definitely seen examples of multiple keys from the same issuer being configured so leaving it in the runtime might be useful for now with the prospect of adding support to the tool later on.