JSON Web Key Sets (JWKS) for Blazor WebAssembly App with Individual Accounts and ASP.NET Core Hosted

[Ogglas]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I have a Blazor WebAssembly App created with Microsoft Visual Studio with these specifications: Target Framework .NET 7.0, Authentication Type Individual Accounts and ASP.NET Core Hosted (Duende IdentityServer):

If I start this project and visit https://localhost:1234/.well-known/openid-configuration/jwks I can see the following values:

{
    "keys": [
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "BAE012345",
            "kty": "RSA",
            "n": "1234567890abc...",
            "use": "sig"
        },
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "Development",
            "kty": "RSA",
            "n": "1234567890abc...",
            "use": "sig"
        }
    ]
}

The Development key is probably generated via appsettings.Development.json and the following value:

  "IdentityServer": {
    "Key": {
      "Type": "Development"
    }
  }

What is the extra key that I can see there and how is it generated?

If I then put this in production and use a cert instead I can see the following values:

{
    "keys": [
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "44A512345",
            "kty": "RSA",
            "n": "1234567890abc...",
            "use": "sig"
        },
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "A60912345",
            "kty": "RSA",
            "n": "1234567890abc...",
            "use": "sig"
        },
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "77C012345",
            "kty": "RSA",
            "n": "1234567890abc...",
            "use": "sig",
            "x5c": [
                "1234567890abc..."
            ],
            "x5t": "1234567890abc..."
        }
    ]
}

Config:

  "IdentityServer": {
    "Key": {
      "Type": "Store",
      "StoreName": "My",
      "StoreLocation": "CurrentUser",
      "Name": "CN=blazortest123"
    }
  },

The last value is my certificate, 77C012345. The other two keys are not generated by me, What is their functionality and how can I disable them?

If I install Duende IdentityServer Templates like this:

dotnet new --install Duende.IdentityServer.Templates

https://docs.duendesoftware.com/identityserver/v5/quickstarts/0_overview/

Then create a new project with template: "Duende IdentityServer with ASP.NET Core Identity (Duende Software)". If I then start the project and visit the jwks endpoint I can see one key as expected.

https://localhost:5001/.well-known/openid-configuration/jwks

{
    "keys": [
        {
            "alg": "RS256",
            "e": "AQAB",
            "kid": "5BFB12345",
            "kty": "RSA",
            "n": "1234567890abc...",
            "use": "sig"
        }
    ]
}

The key that I can see is located in the folder keys and named is-signing-key-5BFB12345.json with value:

{
    "Algorithm": "RS256",
    "Created": "2023-02-06T10:47:05.0718361Z",
    "Data": "1234567890abc...",
    "DataProtected": true,
    "Id": "5BFB12345",
    "IsX509Certificate": false,
    "Version": 1
}

Describe the solution you'd like

If there are extra keys generated, that are used to verify the signature of a signed JWT that the programmer by default has no control over, these should be removed immediately imao.

Additional context

No response

[Ogglas]

@leastprivilege Do you have any input here or do you simply recommend migrating? :)

https://docs.duendesoftware.com/identityserver/v6/upgrades/spa_to_duende/#migrating

[javiercn]

@Ogglas I think this might have broken in one of the Identity Server updates.

I believe that what is happening is that our configuration is not taking effect. I suggest you configure this directly in Identity Server instead of going through our integration layer.

I believe they have built-in support for config now.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Ogglas]

@javiercn Alright but then it seems there are extra keys used to verify the signature of a signed JWT in your template code. This seems like a security vulnerability that we/you need to handle asap or am I being wrong?

To mitigate this do you mean removing .AddApiAuthorization<ApplicationUser, ApplicationDbContext>(); from builder.Services.AddIdentityServer()? Given that we use default Blazor WebAssembly App with Individual Accounts this could mean quite a large rewrite. We use roles in the application as well from the guide below with API authorization options.

https://learn.microsoft.com/en-us/aspnet/core/blazor/security/webassembly/hosted-with-identity-server?view=aspnetcore-6.0&tabs=visual-studio#name-and-role-claim-with-api-authorization-1

We used a Profile Service before but that only works with Authorization Code Grant and not Resource Owner Password Credentials.

https://stackoverflow.com/a/74058054/3850405
https://stackoverflow.com/a/74058226/3850405

The reason we are using ROPC and not Client Credentials flow can be seen below:

#44122

It feels weird to use Resource Owner Password Credentials grant given that it probably will be omitted from OAuth 2.1 in new development so I hope the bug above will be looked at as well.

https://oauth.net/2.1/

Longer term I hope you replace Duende.IdentityServer with Microsoft.AspNetCore.Identity or a similar library created/maintained by Microsoft that is my suggestion below:

#46131

[Ogglas]

@blowdart Can you have a look at this? It seems there are extra keys used to verify the signature of a signed JWT in your template code. This seems like a security vulnerability that we/you need to handle asap or am I being wrong?

[javiercn]

@Ogglas the keys are generated and managed by identity server automatically. As long as those keys are appropriately generated and protected (which they are), there is no security issue here, just a bug.

For it to be a security issue there should be a way in which an attacker could exploit that, which as far as we know, there isn't.

[blowdart]

I believe this is Duende's developer time support for in memory keys, which only lights up when you're in the developer environment, which is controlled by the environment variable asp.net uses. I agree with @javiercn here, and remove the older direct integration stuff if you don't want this key created in memory during dev time. It's not a bug however, it is, to be cliched, a feature, it makes it easier in dev so you don't have to generate and persist keys.

[Ogglas]

@blowdart I don't think that is correct. The issue is present in production as well using a certificate as key so it is not limited to the developer environment. I made a snippet about that in my original post.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.