Check session fails if sts server has a different origin than the check_session_iframe

[Zortaniac]

Describe the bug
When the OICD provider configuration of the sts server contains a different origin for the check_session_iframe property the checkSession will fail with the following error:

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://issuer.org') does not match the recipient window's origin ('https://auth.org').

To Reproduce
Steps to reproduce the behaviour:

1. Use issuer as stsServer in config to resolve well-known configuration
2. Login using an IdentityServer that provides a different issuer URL as the check_session_iframe
3. Wait for the checkSession to be invoked
4. See the error in the console

Expected behavior
checkSession should use the origin of the sessionCheckIFrameUrl to communicate using postMessage.

Config

oidcConfigService.withConfig({
	stsServer: "https://issuer.org",
	redirectUrl: window.location.origin,
	postLogoutRedirectUri: window.location.origin,
	triggerAuthorizationResultEvent: true,
	clientId: clientId,
	scope: scope,
	responseType: 'code',
	startCheckSession: true,
	renewUserInfoAfterTokenRenew: true
});

{
	"issuer": "https://issuer.org",
	"jwks_uri": "https://issuer.org/.well-known/openid-configuration/jwks",
	"authorization_endpoint": "https://auth.org/connect/authorize",
	"token_endpoint": "https://auth.org/connect/token",
	"userinfo_endpoint": "https://auth.org/connect/userinfo",
	"end_session_endpoint": "https://auth.org/connect/endsession",
	"check_session_iframe": "https://auth.org/connect/checksession",
    	...
}

Workaround and additional issue
I found a workaround for this issue by just setting the stsServer to "https://auth.org" what also servers the same provider configuration document as the "https://issuer.org", but this leads me to another issue I discovered.

According to the OpenID Connect Discovery specification the issuer must be used to retrieve the configuration and the issuer returned in the configuration must be the same as the one used to retrieve the configuration.

Currently that is not the case. The stsServer or authWellknownEndpoint configuration property is used to retrieve the provider configuration. Afterwards the issuer returned from that configuration is used to validate the token issuer.

I would expect that the issuer entry from the provider configuration is validated against the stsServer.

[damienbod]

@Zortaniac thanks!

LGTM

@FabianGosebrink ?

will test today and merge.

[damienbod]

thanks for the PR! @Zortaniac This will be released in version 11.4.1

[Zortaniac]

@damienbod thanks for the fast processing of the PR!