- Applications that authenticate OpenIddict clients with client assertions, that is `private_key_jwt` or `client_secret_jwt`, and use the same client signing key on more than one OpenIddict authorization server.
**What changed**
- OpenIddict is upgraded from **7.5.0** to **7.7.0**, which fixes [GHSA-925x-4h4v-2792](https://github.com/openiddict/openiddict-core/security/advisories/GHSA-925x-4h4v-2792). The server stack compared only the path of the `aud` claim with the issuer of the authorization server, so a client assertion minted for one server was accepted by another one that shared the client's signing key.
- The audience of a client assertion still has to be the issuer URI of the server that receives it, with or without the trailing slash, so an assertion that was already addressed to the right server keeps working. A correctly configured client needs no change.
- A single authorization server instance, or several instances with their own cryptographic material, was never affected.
**What to do**
Upgrade the packages. There is no configuration change.
Until you can upgrade, give every authorization server its own client signing key, so an assertion cannot be replayed across them.
### Dependency Updates
**Who is affected**
- Applications that use EF Core with MySQL, directly reference MudBlazor, or pin transitive package versions.
- Applications that pin any of the packages below in their own `.csproj` files. The startup templates pin several of them, so a solution generated before v10.7 has them.
- Applications that use EF Core with MySQL, or directly reference MudBlazor or Blazorise.
**What changed**
- MudBlazor is upgraded from **9.4.0** to **9.7.0**.
- The `Microsoft.AspNetCore.*`, `Microsoft.EntityFrameworkCore.*`, `Microsoft.Extensions.*` and `System.*` packages are upgraded from **10.0.9** to **10.0.11**, and the `Microsoft.IdentityModel.*` packages and `System.IdentityModel.Tokens.Jwt` from **8.19.1** to **8.19.2**. OpenIddict 7.7.0 requires these versions.
- `Microsoft.AspNetCore.DataProtection` is added as a direct dependency.
- MudBlazor is upgraded from **9.4.0** to **9.7.0**, and the Blazorise packages from **2.2.1** to **2.3.0**.
- `MySql.EntityFrameworkCore` is upgraded from **10.0.1** to **10.0.9**.
- `MongoDB.Driver` is upgraded from **3.10.0** to **3.11.1**, and `AWSSDK.S3` and `AWSSDK.SecurityToken` to their current versions.
- ABP maps `Guid[]` query parameters through its own type mapping plugin on MySQL, and stores `IdentityUserPasskey.Data` as a serialized `json` column, because the MySQL providers support neither EF Core JSON columns nor primitive collections. The column name and the stored content stay the same.
**What to do**
Review direct MudBlazor references, align them with ABP's package versions, and re-test customized MudBlazor components and forms after upgrading.
Upgrading the ABP packages does not move the versions you pin yourself, and `abp update` rewrites `Volo.*` references only. A reference that stays below what ABP requires fails the restore, so align those versions in your own `.csproj` files.
These are the ones a solution generated by the startup templates hits:
A solution that pins other packages of these families can hit the same error on them, so see the [Package Version Changes](../../package-version-changes.md) document for the full list and align the rest as well, to keep your solution on one set of versions.
Review direct MudBlazor and Blazorise references, align them with ABP's package versions, and re-test customized components and forms after upgrading.
If you use the MySQL provider, align your own `MySql.EntityFrameworkCore` reference with ABP's version.
Engincan VESKE
12 hours ago
GitHub