- changed title to add RP frame / parent window communication cross-origin note
add RP frame / parent window communication cross-origin note
I think it would be useful for client implementers to have the following hint in the Session Management 1.0 specification section 4.1 (RP iframe).
Note that in deployments with multiple subdomains sharing the same RP session it is important that the parent window and RP iframe both set the same
document.domain
to get around same-origin restrictions. This will allow the RP iframe to target the parent window's embedded OP iframe.
example:
actors:
idp.com
- is the identity provider, offers session management and has an OP frame, uses the redirect_uri Origin to form the session_state
www.rp.com
- is the main client content page that wishes to have users logged in
account.rp.com
- is the client that communicates withidp.com
, the redirect_uri used is from this domainflow:
1) user clicks login on
www.rp.com
2)www.rp.com
usesaccount.rp.com
to trigger oidc authentication flow
3) user logs in atidp.com
, idp redirects back toaccount.rp.com
4)account.rp.com
finishes the auth flow and when finished the second level domain gets a global session set byaccount.rp.com
so thatwww.rp.com
knows there is a user logged in
5) user gets redirected back to the content atwww.rp.com
6)www.rp.com
embeds the OP iframe
7)www.rp.com
setsdocument.domain = 'rp.com';
8)www.rp.com
embeds the RP iframe fromaccount.rp.com
that has the session state
9) the RP frame also setsdocument.domain = 'rp.com';
The RP iframe targets the embedded OP iframe now without issues and sends messages with the expected Origin and is able to notify the parent window (
www.rp.com
) about any changes or errors.
Comments (5)
-
reporter -
-
assigned issue to
We will do this, per the 17-Jan-19 call
-
assigned issue to
-
- changed status to open
-
- changed status to resolved
Fixed
#1038- Add RP iframe / parent window communication cross-origin note→ <<cset f90cdc9dbd95>>
-
Hi,
is this hint still a valid advice? https://developer.mozilla.org/en-US/docs/Web/API/Document/domain
It looks like Chrome is already planning removal of the document.domain setter with version 106 (despite keeping the door open with an opt-in mechanism through additional headers) and Mozilla is on track for prototyping the deprecation due to the risks introduced by the setter.
Thanks,
Davide
- Log in to comment