checkSession fails when issuer has a different origin as the check_session_iframe

[MartijnKooij]

Describe the bug
When the discovery document contains a different origin for the issuer as for the check_session_iframe properties 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://ui-endpoint.org').

To Reproduce
Steps to reproduce the behavior:

1. Login using an IdentityServer that provides a different issuer URL as the check_session_iframe
2. Wait for the checkSession to be invoked
3. See the error in the console

Expected behavior
checkSession uses sessionCheckIFrameUrl if it is provided. Maybe it could/should use the issuer as a fallback but I'm not sure of that.

Config

const authCodeFlowConfig: AuthConfig = {
	issuer: 'https://issuer.org',
	redirectUri: window.location.origin,
	postLogoutRedirectUri: window.location.origin,
	silentRefreshRedirectUri: window.location.origin + '/silent-refresh.html',
	sessionChecksEnabled: true,
	clientId: 'content_factory',
	responseType: 'code',
	scope: 'openid',
	showDebugInformation: true,
	useSilentRefresh: true,
	strictDiscoveryDocumentValidation: false
};

this.oauthService.events.subscribe(event => {
	if (event instanceof OAuthErrorEvent) {
		console.error(event);
	} else {
		console.warn(event);
	}
});

this.oauthService.setStorage(localStorage);
this.oauthService.configure(authCodeFlowConfig);
this.oauthService.setupAutomaticSilentRefresh();

await this.oauthService.loadDiscoveryDocumentAndTryLogin();

this.isDoneLoadingSubject$.next(true);

{
	"issuer": "https://issuer.org",
	"jwks_uri": "https://issuer.org/.well-known/openid-configuration/jwks",
	"authorization_endpoint": "https://ui-endpoint.org/connect/authorize",
	"token_endpoint": "https://ui-endpoint.org/connect/token",
	"userinfo_endpoint": "https://ui-endpoint.org/connect/userinfo",
	"end_session_endpoint": "https://ui-endpoint.org/connect/endsession",
	"check_session_iframe": "https://ui-endpoint.org/connect/checksession",
	"revocation_endpoint": "https://ui-endpoint.org/connect/revocation",
	"introspection_endpoint": "https://ui-endpoint.org/connect/introspect",
	"frontchannel_logout_supported": true,
	"frontchannel_logout_session_supported": true,
	"backchannel_logout_supported": true,
	"backchannel_logout_session_supported": true,
	"scopes_supported": [
		"openid",
		"profile",
		"offline_access"
	],
	"claims_supported": [
		"sub"
	],
	"grant_types_supported": [
		"authorization_code",
	],
	"response_types_supported": [
		"code",
		"token",
		"id_token",
		"id_token token",
		"code id_token",
		"code token",
		"code id_token token"
	],
	"response_modes_supported": [
		"form_post",
		"query",
		"fragment"
	],
	"token_endpoint_auth_methods_supported": [
		"client_secret_basic",
		"client_secret_post"
	],
	"subject_types_supported": [
		"public"
	],
	"id_token_signing_alg_values_supported": [
		"RS256"
	],
	"code_challenge_methods_supported": [
		"plain",
		"S256"
	],
	"request_parameter_supported": true
}

[jeroenheijmans]

Interesting issue, thx for suggesting the PR!

Didn't dive too deep into this yet, but an initial question: is the change compatible with the spec? That is, does the OIDC spec allow for the domains/hosts to be different?

[MartijnKooij]

I don't think it's specified, but I am by no means an expert on the spec of OIDC. So this is just my interpretation of this DRAFT spec.
Also in the main OIDC spec itself I could find no indication of limitations/guidance on endpoint origins.

https://openid.net/specs/openid-connect-session-1_0.html#EndpointDiscovery

[MartijnKooij]

Not wanting to rush you, but also not wanting to release our application with this issue.
Do you perhaps have an update on this @jeroenheijmans or @manfredsteyer ?

Or does anyone perhaps know a workaround, I don't think there's a hook to override this default behavior right?

[jeroenheijmans]

Don't think I'll have time in the short term to deep dive into this, certainly not in the short term. Manfred tends to do updates in batches every few months. And besides the two of us, there's not a whole lot of active users - except for the cases where a community member would completely investigate and solve their own issue.

[MartijnKooij]

I can spend some more time on it but I don't really know where to start. Other than reading the spec which appears to leave quite a bit open to interpretation, or at least does not mention that it is not allowed.

And about my secondary question, do you perhaps have some guidance on ways to work around this issue or are there simply no hooks provided for this right now?

[jeroenheijmans]

I'm not sure what a workaround would be, as I'm not sure what the problem is. Heck, I wouldn't even know if it is a problem with this library, or a problem with your specific IDS (setup)? Sorry :'(

Looking back at your specific error message though, I think you should further debug your setup, and check with your IDS provider (or investigate, if you're building your own). Having separate origins for parts of the IDS is not something I have encountered or seen before, and my guess would be the problem lies there.

If you look for example at IdentityServer4's check session page source you will see that it has this code that causes the postMessage:

var result = calculateSessionStateResult(e.origin, e.data);
e.source.postMessage(result, e.origin);

This is outside control for this Angular library. It's purely JS code served by IdentityServer4. If e.origin doesn't match where stuff was served, then I can imagine this (rightfully) blocks.

Hope that helps a bit. Good luck.

[MartijnKooij]

The IdS is configured the way we need it, with a different origin for the isssuer + jwks URIs as for all the auth/session endpoints. As shown in the provided discovery document.
IdentityServer supports configuring these origins differently and as mentioned the spec does not disallow it either. So even though it might not be common, I don't think it is wrong.

What happens in this library (as well as the one from Damien Bod which we checked out to see if switching would help) is this:

1. The library creates an iframe with the src set to the endpoint listed in check_session_iframe, e.g. https://ui-endpoint.org/connect/checksession.
2. At an interval the library wants to check the session is still valid. Is does this by composing a message (client id + session state) and it tries to post that message to the iframe.
3. For the actual postMessage the library uses the issuer URL as the targetOrigin parameter, e.g. iframe.contentWindow.postMessage(message, 'https://issuer.org');
4. Because the targetOrigin does not match the origin of the iframe we set earlier, the browser will not dispatch the message and the session check will fail, as defined in the HTML postMessage spec

If the library would use the origin of the endpoint defined in check_session_iframe as the targetOrigin in the postMessage it would comply with the same origin policy.

The IdS4 example you reference basically does exactly this, it posts the message back to the origin of the source of the message (e.g. the SPA that is using this library which has created the iframe showing the IdS checksession page).

As for working around the issue a brute force way would be to override the OAuthService.checkSession prototype, but since it is using private and protected methods and properties I have not succeeded at this yet...

[MartijnKooij]

Though they do not implement the check session the discovery document from Google Accounts also shows the use of different origins for different endpoints.
Not saying that they hold the truth about what's the correct implementation of OIDC, but just trying to show that tiny little me is not the only one that has setup different origins in his IdS.

[MartijnKooij]

As a temporary (hopefully) workaround I can override the prototype's checkSession method.

const originalCheckSession = () => OAuthService.prototype.checkSession;
OAuthService.prototype.checkSession = function () {

	const originalIssuer = this.issuer;
	const sessionCheckIFrameOrigin = new URL(this.sessionCheckIFrameUrl || this.issuer).origin;

	this.issuer = sessionCheckIFrameOrigin;

	originalCheckSession();

	this.issuer = originalIssuer;
};

[makdeniss]

We encountered the same issue with our FE applications. One of the IS clients doesn't support url in the issuer field so the IS team had to do a workaround for them, which then leaked to the remaining IS clients. That's where things went downhill. Session checks do not work currently because of this. Maybe there is another way to listen to log out events from other clients so that SSO is working as is on the FE? @manfredsteyer @jeroenheijmans

[jeroenheijmans]

Session checks via iframes is the only standards-based approach I know of. Just brainstorming, other options I could think of:

• make it an API (application) concern to notify folks of logout
• use an in-browser mechanism for cross-tab notifications (e.g. one tab could notify another that a logout occurred)
• make (silent) refreshes far more frequent

[makdeniss]

@jeroenheijmans
one workaround I see is that we catch an event of being logged out from this library and then doing the logout manually...