Session handling in the OpenID Connect Provider from BankID builds on Keycloack session handling. The Keycloak's cookie-based single sign-on feature that is part of Keycloack is however not supported. The OIDC Provider from BankID supports single sign-on via ID Tokens. The following sub-sections describe session handling in more detail:

Session lifetime

The following figure shows events (1-9) related to session handling for the code grant flow. The series of events is further described below and is similar for other supported flows except from the exchange of authorization code (2) before session start. A new session is started (3) when a set of tokens is issued and returned to the requesting OIDC client in step 3. The lifetimes of the ID- and Access Token Tokens are synchronized to a value of 300 seconds. The session is considered active in this forward session window (5). After At token expiry of these tokens (5) the session is considered inactive until the corresponding Refresh Token is also expired (8). Hence, the lifetime of refresh tokens define session lifetime. The session can however be refreshed (6) within this interval, effectively prologing the session with the OIDC Provider. As long as the session has not ceased, a new set of tokens can always be retrived via the foregoing refresh token. 

Note that no new authentiation of session refresh happens silenty without any interaction with the end-user happens at session refresh. Renewed authentication of the end user will happen only when the OIDC client makes a new autorize authorize request, regardless of any existing session. The only exception is if the id_login_hint option is used in the autorize authorize request and there is already an existing session in its active state (ie. a valid ID Token). In this case a new session is started without any end user authentication. Note however that consent handling is still performed in this case. The end user may be asked for consent if the set of requested scopes is wider than the scopes associated with ID Token used in the request.

...

1. Request to Authorize endpoint starts any interaction with end user (if requried)
2. Response from Authorize endpoint after successful authentication of end user. Session is in pending state until authorization code is exchange with tokens. Exchange of code must happen before code expiry (4)
3. Request/response to Token endpoint to exchange authorization code with original set of tokens (ID Token, Access Token, Refresh Token). Session is in active state in a forward session window until expiry of ID- and Access Tokens (5). Session must be refreshed before expiry of original refresh token (8)
4. Authorization code expires
5. Original ID- and Access Tokens expire. Session is in inactive state until session is refreshed with a new set of tokens. 
6. Request/response to Token endpoint to refresh session with new set of tokens (ID Token , Access Token , Refresh Token). Session is in active state until expiry of new ID- and Access Tokens. Session must be refreshed before expiry of new refresh token (9)
7. New ID- and Access Tokens expire. Session is in inactive state until session is refreshed again. 
8. Session would end if it was not refreshed
9. Session ends because it is not refreshed again before expiry of new refresh token.

xxx

yyy

zzz

www