Oidc-client-js: Cross origin not allowed for oidc silent

[jasonmc86]

Use cases where the silent OIDC client callback is hosted on a different domain than where the iframe is created from fails because the domains are checked that they are the same in two places. One the frame postMessage and two the message callback.

Changes similar to #538 would be necessary.

This occurs for example when you want to have a shared OIDC client callback html that is used on different domains.

In these cases it's ideal to be able to configure the different domains rather than host the same callback code on all the different domains (sometimes you don't have access to those domains to change them)

[brockallen]

Use cases where the code that is doing the silent OIDC client callback is hosted on a different domain than where the iframe is created from.
This occurs for example when you might have a shared OIDC client callback html that is used on different domains.

Sorry, I just don't see or understand that use case. Why wouldn't those just be two different clients? I have a feeling I am missing something about your scenario.

In these cases it's ideal to be able to configure the different domains rather than host the same callback code on all the different domains (sometimes you don't have access to those domains to change them)

So then how would the domain you have no control over know to use oidc-client in the first place?

[jasonmc86]

Sorry, I just don't see or understand that use case. Why wouldn't those just be two different clients? I have a feeling I am missing something about your scenario.

• if they are different clients then I still need to host my callback.html in their domain which I cannot do.

So then how would the domain you have no control over know to use oidc-client in the first place?

• I have a script url (hosted on Domain1) that's loads on different domain websites (say domain 2 or 3)
• That script uses oidc to authenticate against (domain 4)
• I've asked domain 4 to have redirect url for my client id to point to domain 1
• domain 4 gives me a silent redirect url back to a callback.html i have hosted on domain 1
• the OIDC client throws an exception because domain of 2 ( or 3) doesn't match domain 1 when the frame posts message
• the OIDC client would also throw an exception if the above step passes when the parent receives the message because it also checks the domains are the same

Domain 1: I have control over. And therefore the iframes domain is D1 whereas the host website is 3 (or 4)
The other domains I don't want to have to make changes to and are out of my control (hence I can't have the redirect url point there)

Let me know if I can clarify further

[jasonmc86]

For the above you can imagine domains 2 or 3 just write a script tag in there website that calls domain 1s script (the same one).

[jasonmc86]

@brockallen thoughts?

[brockallen]

I just worked on a customer that had somewhat of a similar sounding issue. They were building code on salesforce that needed oidc-client to do OIDC, but salesforce makes it hard to build a static web page that can handle the silent renew (mainly the need to have access to the hash fragment values). Does this sound like your situation?

[jedigo]

Hi, I am also in the same situation as @jasonmc86

The use case for us is:

We are currently loading a script to display a common component across a bunch of legacy sites (think of a common page header component across a bunch of legacy sites) , which is using OIDC to get an access token, which is needed to display the shared component.

Although we can add the script to all the legacy sites, it is more involved to get each of them to serve a new static html page for this, so it would be _much_ easier to use a single page on the domain where the script is.

We have tested the patch in https://github.com/IdentityModel/oidc-client-js/pull/538 and this fix works for us.

[jasonmc86]

Hey @brockallen,

It has nothing to do with 'hash fragment values' and sounds like Jeff has
the exact problem we face. Would be good to work together on a solution if
the PR I raised isn't good enough.

Thanks,

Jason

On Thu, 26 Jul 2018, 2:07 AM Jeff Goddard, [e-mail] wrote:

Hi, I am also in the same situation as @jasonmc86
https://github.com/jasonmc86

The use case for us is:

We are currently loading a script to display a common component across a
bunch of legacy sites (think of a common page header component across a
bunch of legacy sites) , which is using OIDC to get an access token, which
is needed to display the shared component.

Although we can add the script to all the legacy sites, it is more
involved to get each of them to serve a new static html page for this, so
it would be much easier to use a single page on the domain where the
script is.

We have tested the pathc in #538
https://github.com/IdentityModel/oidc-client-js/pull/538 and this also
fixes the issue.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/IdentityModel/oidc-client-js/issues/553#issuecomment-407766393,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALUXs9s_nLKp8E_wI4gZUGjR9u3XcidVks5uKHuMgaJpZM4T8kaR
.

[jasonmc86]

Sounds like @ShadSterling also has the problem and has solved it slightly differently in this PR
https://github.com/IdentityModel/oidc-client-js/pull/382

[akand074]

@brockallen we have a similar situation. We currently are stuck with language subdomains, in other words a silent auth can start from say es.example.com but the redirect URI is hardcoded to www.example.com (because of lack of wildcard redirect URIs).

As a result, when the iframe gets to www.example.com/callback?code=<code> it can't notify the parent (es.example.com) to do the exchange code for token.

We can do a workaround by setting the parent subdomain in the state on auth start and read that state in the callback URL to redirect to the right place. But setting the expected source would be safer (albeit not by much).

[brockallen]

Sorry I've not been on top of the issues here. I think at this point I will close, as I don't see a safe way to achieve this.