Open Id connect Session Management

The Open Id connect session management is some what confusing and therefore it’s vital to share some thoughts on session management with implementation details. The discussion will address the session management as defined by Open Id specification (https://openid.net/specs/openid-connect-session-1_0.html) using Relying party Iframe (RPIFrame) and OpenId Provider Iframe (OPIFrame).

Before we dive deep in to session management, it’s important to understand the concept of a session. A session in this context is referred to be the browser session. A session can be initiated at Relying party (RP) or/and OpenId provider (OP). If OP supports session management it will return a special value called session_state in the authentication response. Session_state is an opaque value that get generated at OP side during the authentication process (for instance token generation) and this value is unique for the relying party.

Requirement for the session management

A relying party is interested to know the session state of its logged in users. In order to find the session status RP needs to query the OP periodically (prompt=none). This could be an expensive operation as it could impact network traffic. The session management concept was introduced in order to solve this puzzle.

OIDC session management

OPs which supports session management issues a special parameter called session_state during the authentication process. This is an opaque value which is calculated using given algorithm at the server side and will be unique to each RP. RPs who implement session management should store the session_state in a cookie or HTML 5 storage as this value would be used to detect session changes.

How it works

To support session management RP and OP need to implement two IFrames on their ends. Instead of RP directly communicate with OP, RP IFrame interacts with OP IFrame which would not cause any network overhead. Lets have a deep dive in to each of those IFrames

RP IFrame

• This is an invisible IFrame which resides on RP side. RP IFrame periodically sends messages to OP IFrame using HTML 5 PostMessage Api.
• RP initiates a message as Client ID + “ “ + Session State
• Up on receiving the above message OP IFrame re-calculates the session state and returns following messages back to the RP IFrame.

“changed” session_state is different from what it received. This indicates that the session has been changed due to any possible reason (user signed out, user sign in to a different RP). As a result RP should perform a silent authentication using prompt=none parameter. Up on calling the authentication endpoint, OP will check whether user should be re-authenticated and if so it will return as login_required. If not RP can either still acquire new tokens or ignore.

“unchanged” session state changed where RP can ignore

“error” error calculating session state at OPIFrame. This behavior could be business specific but the OIDC guidance specify that we should not perform silent authentication as this could potentially lead to an infinite loop

OP_IFrame

This invisible IFrame hosted by OpenId Id provider in “check_session_iframe” and relying parties loads the IFrame inside the agent. OP IFrame reads messages received from RP_IFrame and re-calculate the session_state at agent side. After that it compares this session_state value with what it received from RP_IFrame.

When the session_states are similar OP_IFrame will return the message “unchanged” and “changed” otherwise.

Summary

This article has discussed the OIDC session management with implementation details. The concept of RPIFrame and OPIFrame w ere defined with sample codes. Please follow the next topic to get the full insight on back channel logout.