Oauth profile issue

Solace Event Broker
1

We have two OAuth Profiles configured against the same XSUAA issuer.

  • AEM_XSUAA_AUTH (Disabled)
  • aem_cf (Enabled)

Both have the same Issuer Identifier, JWKS URL and Resource Server. Only the OAuth Client ID/Secret differ.

Client Authentication is enabled and the Default Profile is still AEM_XSUAA_AUTH.

A client username (sb-xsuaa-auth-aem!t499931) has no explicit oauth-profile attribute, yet authentication succeeds.

According to the documentation, the broker selects the OAuth Profile using the iss claim and falls back to the Default Profile if necessary.

Question: When multiple OAuth Profiles share the same issuer, how does the broker choose which profile validates the JWT? Does issuer matching take precedence over the Default Profile, and is the Default Profile ignored if another enabled profile matches the issuer?

2

The documented profile-selection algorithm (priority order)

The broker applies this sequence for every incoming token, in strict order:

Priority Mechanism How it works
1 Explicit profile prefix in the token/credential Client embeds ~base64(<issuer>)~ in the bearer token (REST/SEMP), or includes the profile name explicitly in the MQTT password field (OAUTH~<profile>~<token>). The named profile is used directly — bypassing issuer matching and the default profile entirely.
2 iss claim matching against enabled profiles The broker reads the iss claim from the JWT and walks the list of configured profiles looking for one where the Issuer Identifier matches and the profile is enabled. If a match is found, that profile is used.
3 Default Profile fallback Only reached if step 2 produces no match (either the iss claim is absent, the token is not a JWT, or no enabled profile’s issuer matches). The configured Default Profile is then used.

SEMP Authentication and Authorization → “the iss claim in the ID token (for OpenID Connect) or access token (for OAuth 2.0), if present, is used by the event broker to identify which OAuth profile to use. … If a profile cannot be identified from the iss claim in the token, and no issuer prefix is provided in the Authorization header, the default profile is used.” and In general, the iss claim in the ID token (for OpenID Connect) or access token (for OAuth 2.0), if present, is used by the event broker to identify which OAuth profile to use."

What happens in your specific scenario

Setup:

  • AEM_XSUAA_AUTH — Disabled, same issuer as below, is the Default Profile
  • aem_cf — Enabled, same issuer

Why sb-xsuaa-auth-aem!t499931 authenticates successfully:

  1. The broker reads the iss claim from the JWT.
  2. It scans for a profile whose Issuer Identifier matches the iss claim and is enabled.
  3. AEM_XSUAA_AUTH is disabled — the broker skips it in the issuer-match scan (a disabled profile is not a valid candidate for issuer-based selection).
  4. aem_cf is enabled and its issuer matches — the broker selects it.
  5. Token validation proceeds against aem_CF. :white_check_mark:

The Default Profile (AEM_XSUAA_AUTH) is never consulted because issuer-matching against aem_cf succeeded. The Default Profile is only the fallback of last resort.

Key takeaways

  1. Issuer matching always takes precedence over the Default Profile. The Default Profile is not consulted if any enabled profile matches the iss claim.

  2. Disabled profiles are invisible to the issuer-match scan. A disabled profile is skipped as a candidate, even if its issuer would have matched. This is the critical detail in your setup: the broker effectively sees only aem_cf when matching the XSUAA iss claim.

  3. The Default Profile being disabled is not problematic here. Since AEM_XSUAA_AUTH is never reached (because aem_cf matches first), its disabled state causes no authentication failure. The Default Profile only matters if the broker reaches step 3 — i.e., there is no iss claim or no enabled profile matches.

  4. If both profiles were enabled and shared the same issuer, the documentation does not define a deterministic tie-breaking rule. This would be an ambiguous configuration — only one profile would be selected (likely the first one encountered internally), and you would have no guarantee of which one wins. The recommended and supported pattern is to have each issuer map to exactly one enabled profile.

  5. sb-xsuaa-auth-aem!t499931 having no explicit oauth-profile attribute is entirely consistent with this outcome: the issuer-based auto-selection mechanism handles it. Explicit profile attributes on the client username are not required when the issuer is unambiguously matchable.

Recommendation

Your current configuration works by accident of AEM_XSUAA_AUTH being disabled. If you were to re-enable it in the future, you would have two enabled profiles with the same issuer — an undocumented tie-break situation. To make the setup unambiguous and maintainable:

  • Either keep AEM_XSUAA_AUTH disabled (as now), or delete it if it’s no longer needed.
  • If you need two profiles for the same XSUAA issuer (e.g., different Client IDs for different services), use explicit profile selection in the client credentials (the ~base64(<issuer>)~ prefix or the MQTT OAUTH~<profile>~ password form) rather than relying on issuer auto-selection.

Hope this clarifies matters.