[dependabot]

Updated Aguacongas.IdentityServer.Admin.Duende from 11.0.3 to 11.0.4.

Release notes

Sourced from Aguacongas.IdentityServer.Admin.Duende's releases.

11.0.4

11.0.4 (2026-11-05)

Security Fixes

• GHSA-mw4v-v5j2-7f3g (a7e7798)

News options are available to control dynamic client registration:

By default, clients created by dynamic registration are protected as follows:

• A native application using only the authorization_code and refresh_token grant types is a public client: it has no client secret requirement, and PKCE is required.
• Any other client (web applications, or clients using other grant types such as client_credentials) must authenticate at the token endpoint.
• PKCE is required for every client using the authorization_code grant type.
• A web client using the authorization code flow must register https redirect URIs. http is accepted only for loopback hosts (localhost, 127.0.0.1, [::1]).

Web clients using the implicit grant type must still use https redirect URIs and cannot use localhost, and native clients keep their own redirect URI rules.

You can adjust these protections with the following options.

Option	Default	Description
RequirePkce	Always	Always: PKCE is required for all clients using the authorization code flow. PublicClientsOnly: PKCE is required only for public clients. Never: PKCE is never required.
RequireClientAuthentication	true	When false, no client created by dynamic registration is required to authenticate at the token endpoint (all clients are public).
RequireHttpsRedirectUris	true	When false, web clients using the authorization code flow can register http redirect URIs.
AllowLoopbackHttpRedirectUris	true	When RequireHttpsRedirectUris is true, accepts http redirect URIs on loopback hosts.

"DynamicClientRegistrationOptions": {
  "RequirePkce": "PublicClientsOnly",
  "RequireClientAuthentication": true,
  "RequireHttpsRedirectUris": true,
  "AllowLoopbackHttpRedirectUris": true
}

The server logs a warning at startup when one of these options is relaxed.

Without PKCE and client authentication, an authorization code intercepted by an attacker can be exchanged with only the client identifier. Keep the default values unless you need to accept clients that can't support them, for example to run a conformance test suite that doesn't send a PKCE code challenge.

These options apply when a client is registered or updated. Clients created before the upgrade keep their settings, check clients created by dynamic registration that have RequirePkce or RequireClientSecret set to false and use the authorization_code grant type.

Commits viewable in compare view.

Updated Aguacongas.IdentityServer.EntityFramework.Store.Duende from 11.0.3 to 11.0.4.

Release notes

Sourced from Aguacongas.IdentityServer.EntityFramework.Store.Duende's releases.

11.0.4

11.0.4 (2026-11-05)

Security Fixes

• GHSA-mw4v-v5j2-7f3g (a7e7798)

News options are available to control dynamic client registration:

By default, clients created by dynamic registration are protected as follows:

• A native application using only the authorization_code and refresh_token grant types is a public client: it has no client secret requirement, and PKCE is required.
• Any other client (web applications, or clients using other grant types such as client_credentials) must authenticate at the token endpoint.
• PKCE is required for every client using the authorization_code grant type.
• A web client using the authorization code flow must register https redirect URIs. http is accepted only for loopback hosts (localhost, 127.0.0.1, [::1]).

Web clients using the implicit grant type must still use https redirect URIs and cannot use localhost, and native clients keep their own redirect URI rules.

You can adjust these protections with the following options.

Option	Default	Description
RequirePkce	Always	Always: PKCE is required for all clients using the authorization code flow. PublicClientsOnly: PKCE is required only for public clients. Never: PKCE is never required.
RequireClientAuthentication	true	When false, no client created by dynamic registration is required to authenticate at the token endpoint (all clients are public).
RequireHttpsRedirectUris	true	When false, web clients using the authorization code flow can register http redirect URIs.
AllowLoopbackHttpRedirectUris	true	When RequireHttpsRedirectUris is true, accepts http redirect URIs on loopback hosts.

"DynamicClientRegistrationOptions": {
  "RequirePkce": "PublicClientsOnly",
  "RequireClientAuthentication": true,
  "RequireHttpsRedirectUris": true,
  "AllowLoopbackHttpRedirectUris": true
}

The server logs a warning at startup when one of these options is relaxed.

Without PKCE and client authentication, an authorization code intercepted by an attacker can be exchanged with only the client identifier. Keep the default values unless you need to accept clients that can't support them, for example to run a conformance test suite that doesn't send a PKCE code challenge.

These options apply when a client is registered or updated. Clients created before the upgrade keep their settings, check clients created by dynamic registration that have RequirePkce or RequireClientSecret set to false and use the authorization_code grant type.

Commits viewable in compare view.

Updated Aguacongas.IdentityServer.Http.Store from 11.0.3 to 11.0.4.

Release notes

Sourced from Aguacongas.IdentityServer.Http.Store's releases.

11.0.4

11.0.4 (2026-11-05)

Security Fixes

• GHSA-mw4v-v5j2-7f3g (a7e7798)

News options are available to control dynamic client registration:

By default, clients created by dynamic registration are protected as follows:

• A native application using only the authorization_code and refresh_token grant types is a public client: it has no client secret requirement, and PKCE is required.
• Any other client (web applications, or clients using other grant types such as client_credentials) must authenticate at the token endpoint.
• PKCE is required for every client using the authorization_code grant type.
• A web client using the authorization code flow must register https redirect URIs. http is accepted only for loopback hosts (localhost, 127.0.0.1, [::1]).

Web clients using the implicit grant type must still use https redirect URIs and cannot use localhost, and native clients keep their own redirect URI rules.

You can adjust these protections with the following options.

Option	Default	Description
RequirePkce	Always	Always: PKCE is required for all clients using the authorization code flow. PublicClientsOnly: PKCE is required only for public clients. Never: PKCE is never required.
RequireClientAuthentication	true	When false, no client created by dynamic registration is required to authenticate at the token endpoint (all clients are public).
RequireHttpsRedirectUris	true	When false, web clients using the authorization code flow can register http redirect URIs.
AllowLoopbackHttpRedirectUris	true	When RequireHttpsRedirectUris is true, accepts http redirect URIs on loopback hosts.

"DynamicClientRegistrationOptions": {
  "RequirePkce": "PublicClientsOnly",
  "RequireClientAuthentication": true,
  "RequireHttpsRedirectUris": true,
  "AllowLoopbackHttpRedirectUris": true
}

The server logs a warning at startup when one of these options is relaxed.

Without PKCE and client authentication, an authorization code intercepted by an attacker can be exchanged with only the client identifier. Keep the default values unless you need to accept clients that can't support them, for example to run a conformance test suite that doesn't send a PKCE code challenge.

These options apply when a client is registered or updated. Clients created before the upgrade keep their settings, check clients created by dynamic registration that have RequirePkce or RequireClientSecret set to false and use the authorization_code grant type.

Commits viewable in compare view.

Updated Aguacongas.TheIdServer.Authentication from 11.0.3 to 11.0.4.

Release notes

Sourced from Aguacongas.TheIdServer.Authentication's releases.

11.0.4

11.0.4 (2026-11-05)

Security Fixes

• GHSA-mw4v-v5j2-7f3g (a7e7798)

News options are available to control dynamic client registration:

By default, clients created by dynamic registration are protected as follows:

• A native application using only the authorization_code and refresh_token grant types is a public client: it has no client secret requirement, and PKCE is required.
• Any other client (web applications, or clients using other grant types such as client_credentials) must authenticate at the token endpoint.
• PKCE is required for every client using the authorization_code grant type.
• A web client using the authorization code flow must register https redirect URIs. http is accepted only for loopback hosts (localhost, 127.0.0.1, [::1]).

Web clients using the implicit grant type must still use https redirect URIs and cannot use localhost, and native clients keep their own redirect URI rules.

You can adjust these protections with the following options.

Option	Default	Description
RequirePkce	Always	Always: PKCE is required for all clients using the authorization code flow. PublicClientsOnly: PKCE is required only for public clients. Never: PKCE is never required.
RequireClientAuthentication	true	When false, no client created by dynamic registration is required to authenticate at the token endpoint (all clients are public).
RequireHttpsRedirectUris	true	When false, web clients using the authorization code flow can register http redirect URIs.
AllowLoopbackHttpRedirectUris	true	When RequireHttpsRedirectUris is true, accepts http redirect URIs on loopback hosts.

"DynamicClientRegistrationOptions": {
  "RequirePkce": "PublicClientsOnly",
  "RequireClientAuthentication": true,
  "RequireHttpsRedirectUris": true,
  "AllowLoopbackHttpRedirectUris": true
}

The server logs a warning at startup when one of these options is relaxed.

Without PKCE and client authentication, an authorization code intercepted by an attacker can be exchanged with only the client identifier. Keep the default values unless you need to accept clients that can't support them, for example to run a conformance test suite that doesn't send a PKCE code challenge.

These options apply when a client is registered or updated. Clients created before the upgrade keep their settings, check clients created by dynamic registration that have RequirePkce or RequireClientSecret set to false and use the authorization_code grant type.

Commits viewable in compare view.

Updated Aguacongas.TheIdServer.Identity from 11.0.3 to 11.0.4.

Release notes

Sourced from Aguacongas.TheIdServer.Identity's releases.

11.0.4

11.0.4 (2026-11-05)

Security Fixes

• GHSA-mw4v-v5j2-7f3g (a7e7798)

News options are available to control dynamic client registration:

By default, clients created by dynamic registration are protected as follows:

• A native application using only the authorization_code and refresh_token grant types is a public client: it has no client secret requirement, and PKCE is required.
• Any other client (web applications, or clients using other grant types such as client_credentials) must authenticate at the token endpoint.
• PKCE is required for every client using the authorization_code grant type.
• A web client using the authorization code flow must register https redirect URIs. http is accepted only for loopback hosts (localhost, 127.0.0.1, [::1]).

Web clients using the implicit grant type must still use https redirect URIs and cannot use localhost, and native clients keep their own redirect URI rules.

You can adjust these protections with the following options.

Option	Default	Description
RequirePkce	Always	Always: PKCE is required for all clients using the authorization code flow. PublicClientsOnly: PKCE is required only for public clients. Never: PKCE is never required.
RequireClientAuthentication	true	When false, no client created by dynamic registration is required to authenticate at the token endpoint (all clients are public).
RequireHttpsRedirectUris	true	When false, web clients using the authorization code flow can register http redirect URIs.
AllowLoopbackHttpRedirectUris	true	When RequireHttpsRedirectUris is true, accepts http redirect URIs on loopback hosts.

"DynamicClientRegistrationOptions": {
  "RequirePkce": "PublicClientsOnly",
  "RequireClientAuthentication": true,
  "RequireHttpsRedirectUris": true,
  "AllowLoopbackHttpRedirectUris": true
}

The server logs a warning at startup when one of these options is relaxed.

Without PKCE and client authentication, an authorization code intercepted by an attacker can be exchanged with only the client identifier. Keep the default values unless you need to accept clients that can't support them, for example to run a conformance test suite that doesn't send a PKCE code challenge.

These options apply when a client is registered or updated. Clients created before the upgrade keep their settings, check clients created by dynamic registration that have RequirePkce or RequireClientSecret set to false and use the authorization_code grant type.

Commits viewable in compare view.

Updated Aguacongas.TheIdServer.Migrations.SqlServer from 11.0.3 to 11.0.4.

Release notes

Sourced from Aguacongas.TheIdServer.Migrations.SqlServer's releases.

11.0.4

11.0.4 (2026-11-05)

Security Fixes

• GHSA-mw4v-v5j2-7f3g (a7e7798)

News options are available to control dynamic client registration:

By default, clients created by dynamic registration are protected as follows:

• A native application using only the authorization_code and refresh_token grant types is a public client: it has no client secret requirement, and PKCE is required.
• Any other client (web applications, or clients using other grant types such as client_credentials) must authenticate at the token endpoint.
• PKCE is required for every client using the authorization_code grant type.
• A web client using the authorization code flow must register https redirect URIs. http is accepted only for loopback hosts (localhost, 127.0.0.1, [::1]).

Web clients using the implicit grant type must still use https redirect URIs and cannot use localhost, and native clients keep their own redirect URI rules.

You can adjust these protections with the following options.

Option	Default	Description
RequirePkce	Always	Always: PKCE is required for all clients using the authorization code flow. PublicClientsOnly: PKCE is required only for public clients. Never: PKCE is never required.
RequireClientAuthentication	true	When false, no client created by dynamic registration is required to authenticate at the token endpoint (all clients are public).
RequireHttpsRedirectUris	true	When false, web clients using the authorization code flow can register http redirect URIs.
AllowLoopbackHttpRedirectUris	true	When RequireHttpsRedirectUris is true, accepts http redirect URIs on loopback hosts.

"DynamicClientRegistrationOptions": {
  "RequirePkce": "PublicClientsOnly",
  "RequireClientAuthentication": true,
  "RequireHttpsRedirectUris": true,
  "AllowLoopbackHttpRedirectUris": true
}

The server logs a warning at startup when one of these options is relaxed.

Without PKCE and client authentication, an authorization code intercepted by an attacker can be exchanged with only the client identifier. Keep the default values unless you need to accept clients that can't support them, for example to run a conformance test suite that doesn't send a PKCE code challenge.

These options apply when a client is registered or updated. Clients created before the upgrade keep their settings, check clients created by dynamic registration that have RequirePkce or RequireClientSecret set to false and use the authorization_code grant type.

Commits viewable in compare view.

Updated OpenTelemetry.Instrumentation.Http from 1.20.1 to 1.20.2.

Release notes

Sourced from OpenTelemetry.Instrumentation.Http's releases.

1.20.2

• NuGet: OpenTelemetry.Extensions.AWS v1.20.2

  No notable changes.

  See CHANGELOG for details.

• NuGet: OpenTelemetry.Instrumentation.AWS v1.20.2

  No notable changes.

  See CHANGELOG for details.

• NuGet: OpenTelemetry.Instrumentation.AWSLambda v1.20.2

  • Fix server.address and server.port not being recorded correctly for HTTP
    requests with an IPv6 address in the Host header (e.g. [::1]:8080).
    (#​5788)

  See CHANGELOG for details.

1.20.2-beta.1

• NuGet: OpenTelemetry.Instrumentation.Hangfire v1.20.2-beta.1

  • Fixed failed jobs exporting the exception message as the span status description.
    The message is now only recorded when RecordException is enabled.
    (#​5884)

  • Fixed baggage from a job being visible to work started by other jobs
    performed on the same worker.
    (#​5886)

  • Added EnrichWithBackgroundJob and CustomStateMappings to
    HangfireMetricsInstrumentationOptions. Use them to add custom attributes to
    the metrics and to count jobs in custom Hangfire states.
    (#​5810)

  • Fixed workflow.execution.duration for the executing state. It included the
    time of other measurements of this instrumentation, for example the database
    query that RecordQueueLatency adds.
    (#​5810)

  See CHANGELOG for details.

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[aguacongas]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[AppVeyorBot]

✅ Build TheIdServer 11.1.0-dependabot-nuget-sample-MultiTiers-Aguacongas-TheIdServer-Private-all-nuget-dependencies-4ffe688e2f1- completed (commit f5e136e2c8 by @dependabot[bot])