Session management

[rohe]

My present thinking is this:

When a user completes a successful authentication at an OP a session is created.
There is one session per user_id and client_id combination.

That means that if the user sends an authentication request from another client and SSO is used then a new session is created. The 2 sessions have an authentication event in common.
If SSO was not allowed then the 2 sessions, even if they concerned the same user_id, would not have a common authentication event.

This means that at the top of the session management tree we would have a number of authentication events.

Now within a session grants can be given. These grants can lead to authorization codes, access tokens and/or refresh tokens to be issued.

So we have a hierarchy:

1. Authentication Event
2. Session
3. Grant

This would allow us easy handling of single logout as well as dealing with grant management as described in
Grant Management

There are connections between grants, for instance it's useful to know which refresh token was used to issue which access token.

[peppelinux]

Let's assume to implement this code refactor, which would be the changements, strictly technicals, about the actual approach?
I mean, for example, the first query on the data persistence regards STATE value, what would be the new flow about the reunification approach to follow, to match an existing sid/sub with an ingoing authz request.

that's something that would be defined in a general documentation (fancy drawings or text).
that would be the start point for developers that would implements third-party storage engines.
We're facing a good opportunity to open a road to this

[peppelinux]

There are connections between grants, for instance it's useful to know which refresh token was used to issue which access token.

Long time not read this ...
I agree, each token and refresh token must be linked to a session. Wondering about SSO Is there some clue about session reuse (base on cookie...) or It Simply rely to have another auth and another session if bearer wasn't submitted in the request?

[rohe]

The documentation are starting to come together. Please read https://new-session-management.readthedocs.io/en/latest/
Not sure I really understand your question.

[peppelinux]

actually "question at night, shame during the day" and I often find it difficult to understand myself!

Overall my question is outside the scope of oidcendpoint because it strictly refers to the implementation of SSO on the provider side and not in how oidcendpoint manages the session internally.

As soon as I can put my hand to the new session management system I will find the answer with something practical but in fact I already read in the documentation you shared:

"""
Note that we are dealing with a Single Sign On (SSO) context here. If for some reason the OP does not want to support SSO then the session management has to be done a bit differently. In that case each session (user_id, client_id) would have its own authentication even. Not one shared between the sessions.
"""

Well, would be great to manage this behavior in oidcendpoint general configuration if you agree

It would be useful - like so many things in this world, so leave the time it finds - to create a "drawing" of the relationship pattern that makes up the management of the session. If I have a chance, I'll report it on the documentation

[rohe]

To make an OP support SSO or not support SSO is pretty simple.
To do it per client is not so simple but can probably be done.

[peppelinux]

To make an OP support SSO or not support SSO is pretty simple.
To do it per client is not so simple but can probably be done.

Correct me if I'm wrong but generally that's would be done with a second cookie crafted for SameSite avoidance and a sid in it - probably crypted and salted - that would be recognized by OP. The cookie wouldn't expire until the session will be refreshed by tokens

[rohe]

Sorry, I was thinking more along the lines that and OP supported SSO for some clients but not for others.

How SSO is handled between the RP and the OP, using cookies or ... was not what I was thinking about.

And yes in the session management subsystem cookies with encrypted content (containing the sid) is used to keep SSO going.

[peppelinux]

Sorry, I was thinking more along the lines that and OP supported SSO for some clients but not for others.

Hey... That's something really interesting!
I never thought about that, thank you, something new

[rohe]

Trust me to come up with something you've never thought of before :-) :-)