Session Management OpenID Connect Why two Iframes?

Question

I have been reading the OpenID Connect draft specification describing how to handle a user log off. Everything points to this super weird, two iframe solution. See here: openid spec for sessions and a brief description here: Hans Zandbelt blog regarding this strategy

can someone explain why I need two separate iframes, and not just one to the openid identity provider, and some javascript on my page to delete the cookie and redirect to the sso login?

Answer 1

I was having the same doubts the other day about why we need two iframes to perform session check. From my point of viewing it, the RP iframe was totally useless. As a matter of fact, it's totally possible to perform the session check with just an iframe pointing to the check_session_iframe url.

The thing is that, when you receive the changed message, you will most likely want to attempt a silent token renewal, as the spec says, and you will need an iframe for doing so, hence the RP iframe.

The spec (4.1 RP Iframe) says:

Upon receipt of changed, the RP MUST perform re-authentication with 
prompt=none to obtain the current session state at the OP. 

When the RP detects a session state change, it SHOULD first try a prompt=none 
request within an iframe to obtain a new ID Token and session state, sending 
the old ID Token as the id_token_hint. 

I believe the RP iframe is responsible for performing the silent token renewal, upon the receive of a changed message. The RP iframe should then generate a new token request with prompt=none, hence the silently part. If the RP iframe fails to silently renew the token, then the user is no longer authenticated, and your application should be notified to perform proper actions.