Session handling in the OpenID Connect Provider from BankID builds on Keycloak session handling. Keycloak's cookie-based single sign-on feature 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 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. The lifetimes of the ID- and Access Tokens are synchronized to a value of 300 seconds. The session is active in this forward session window (5). At token expiry (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 session refresh happens silenty without any interaction with the end-user. Renewed authentication will happen only when the OIDC client makes a new authorize request, regardless of any existing session. The only exception is if the id_login_hint option is used in the 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.

Note also that expire_in in the response from the Token endpoint is always synchronized with the exp value that is contained inside the ID Token and Access Tokens, respectively. This is in contrast to refresh_expires_in contained in the same response. This value is not synchronized with the exp value inside the Refresh Token. The latter value corresponds to the exp value of the ID Token and Access Token, whereas the former defines the forward refresh window and hence the session lifetime.

Note finally that the session lifetime for offline access / offline refresh tokens are governed differently than what is shown below. The logic is pretty much the same. The difference is that offline access is associated with long lived refresh tokens combined with a consent policy making the end user aware that the requesting OIDC client may access resources on the end user behalf also without the user being present in a session with the OIDC Provider from BankID.

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.