Session management

[identitypython]

Session management

[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 :-) :-)