fix: refresh authWellKnownEndpoints when the server updates them

[andsouto]

fix: refresh authWellKnownEndpoints when the server updates them

fix #1983

Problem

When using OIDC discovery, authWellknownEndpoints could be influenced by previously persisted/config-provided values. That made it possible for stale overrides (or cached values) to “win” over the latest server discovery document, preventing the client from correctly refreshing endpoints after the IdP updates them.

What this PR changes

1. Discovery results are authoritative

   • AuthWellKnownDataService no longer merges config.authWellknownEndpoints into the mapped discovery result.
   • Outcome: in discovery mode, the returned endpoints come from the server’s /.well-known/openid-configuration document (i.e., fresh values), instead of being overwritten by potentially stale config overrides.

2. Issuer mismatch is not bypassed by overrides

   • Issuer validation now behaves strictly even if authWellknownEndpoints contains an issuer value.
   • Outcome: a mismatching issuer from discovery still fails fast, rather than being hidden by an override.

3. Explicit endpoints mode is explicit (no discovery request)

   • If authWellknownEndpoints is explicitly provided, AuthWellKnownService returns/stores them and skips the discovery network call.
   • This preserves a clear “either/or” contract:
     • Explicit endpoints: deterministic, no network discovery.
     • Discovery: always fetch fresh endpoints from the server.

4. ConfigurationService no longer hydrates endpoints from storage

   • ConfigurationService stops reading authWellKnownEndPoints from StoragePersistenceService and stamping them onto the runtime config.
   • Outcome: persisted/stale endpoints do not get injected during config loading.

Why these decisions

This PR aims to fix #1983 with the smallest behavior change necessary to ensure refresh correctness:

• In discovery mode, the server must be the source of truth; otherwise refresh can’t be trusted.
• Merging overrides into discovery results reintroduces staleness and can undermine issuer validation.
• If users want to override endpoints intentionally, they can do so explicitly by providing authWellknownEndpoints (and the library won’t perform discovery in that case).

Tests

• Updated/added unit tests cover:
  • No merging of config overrides into discovery results.
  • Issuer mismatch failing even when overrides exist.
  • Explicit endpoints mode skipping discovery and returning explicit endpoints.
  • ConfigurationService not sourcing endpoints from storage.

[Copilot]

Pull request overview

Fixes stale/override persistence issues around OIDC discovery so that refreshed /.well-known/openid-configuration values are used authoritatively, and issuer mismatch checks can’t be bypassed by previously provided/stored endpoint overrides.

Changes:

• Stop hydrating authWellknownEndpoints from storage during configuration loading.
• Make discovery results authoritative by removing merge of config-provided endpoint overrides into mapped discovery endpoints.
• Add an “explicit endpoints” path that stores/returns authWellknownEndpoints and skips the discovery network call.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
projects/angular-auth-oidc-client/src/lib/config/config.service.ts	Removes loading/stamping well-known endpoints from storage during config initialization.
projects/angular-auth-oidc-client/src/lib/config/config.service.spec.ts	Updates unit tests to reflect that config is no longer hydrated from stored endpoints.
projects/angular-auth-oidc-client/src/lib/config/auth-well-known/auth-well-known.service.ts	Adds early return for explicitly configured authWellknownEndpoints (no discovery request).
projects/angular-auth-oidc-client/src/lib/config/auth-well-known/auth-well-known.service.spec.ts	Adds tests for explicit endpoints mode and discovery mode behavior.
projects/angular-auth-oidc-client/src/lib/config/auth-well-known/auth-well-known-data.service.ts	Removes merging of config overrides into discovery results; keeps strict issuer validation behavior.
projects/angular-auth-oidc-client/src/lib/config/auth-well-known/auth-well-known-data.service.spec.ts	Updates tests to ensure no merge occurs and issuer mismatch throws even with overrides present.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[andsouto]

This is an interesting point. IMO we need to take a design decision here to decide between two options:

• authWellknownEndpoints replaces everything and completely avoids the network request to discover endpoints.
• authWellknownEndpoints does not prevent the network request but just overrides things after it.

Personally I have not really an opinion as I'm not using that option. Currently, the PR implements option 1. Any opinion if this is right or if we should go with option 2? Reasons?