Authorization flow does not allow switching accounts

[RubenVerborgh]

Steps to reproduce:

1. Log in as user X on pod A (OIDC mode)
2. (OPTIONAL) Log in on pod B as whatever user and log out again
3. Go to a protected resource on pod B so you are asked to log in
4. Enter pod A as identity provider

Expected result:

• Pod A asks for your username and password (or should at least give you the option to continue or not)

Actual result:

• Pod A logs you in as user X

[dmitrizagidulin]

Is there a Logout step that's involved?

[RubenVerborgh]

Possibly a log out on pod B, added above.

[dmitrizagidulin]

Ok, so, I suspect I know what the problem may be. But let's talk about Logout in general, and what the expected/desired behavior is, for several scenarios. (We should probably add this discussion to the spec, or at least an app dev guide, afterwards).

Our actors are:

Alice, with webid https://alice.podA.com/#me,
Bob, with webid https://bob.podB.com/#me,
and Cindy, with server https://cindy.com.

And all resources in these scenarios are ACL-protected (non public), and users start out non-authenticated unless specified otherwise.

(RS - Resource Server, IdP - Identity Provider, RP - Relying Party).

Scenario 1 - RS/IdP same origin

Alice makes a direct non-AJAX request to an image resource on her own pod

So, Alice: GET https://alice.podA.com/icon.gif

Non-AJAX meaning, let's say she follows a link or types in the URL of an image directly into her browser. And the reason we specify "image resource" is because it's not currently wrapped in Mashlib, it should be returned by the pod directly to the browser.

Her browser makes the GET call, hits a 401, gets redirected to Login, she logs in, gets redirected back to image, sees the image.

Post-Login state: a) A cookie based session to *.podA.com in alice's browser. (Nothing in localStorage). So, she is "logged in to podA".

To Logout (since it's just a raw image, and there's no 'Logout' button anywhere), Alice can visit https://podA.com/logout directly (or clear her cookies or something).

Visiting the /logout endpoint, her pod clears her WebID from the session (so, she still has a session cookie, it's just empty). (If she used her browser to clear her cookie, it'll be deleted, but as soon as she makes another HTTP request to podA.com, the browser will generate another empty session cookie anyways.)

Post-Logout state: a) No state (well, an empty session cookie to podA.com).

Scenario 2 - RS/IdP/RP same origin

Alice visits her "home page" app, clicks Login

Alice: GET https://alice.podA.com/

This loads an HTML page + a JS app that uses a Solid Auth client, and includes a client-powered Login button.

She clicks Login, gets an auth client popup, selects idp, gets redirected to login form (in popup), logs in, popup closes, she is back to her homepage app, now Logged In.

Consent step: Skipped (resource is on same pod as IDP).

Post-Login state: a) A cookie based session to *.podA.com ("Logged in to PodA"), b) A client registration + user session token in localStorage for origin podA.com ("Logged in to Homepage App, with IDP as PodA").

To Logout, she clicks the Logout button. Following actions occur:

1. Client: Clears her session token in localStorage
2. Client: Makes an AJAX call to the IDP's /logout endpoint (determined from the server config during registration)
3. IDP (PodA): Clears her WebID from session cookie (in /logout handler)

Post-Logout state: a) An empty session cookie, b) No user session credentials in localStorage (Note: the auth client currently stores the app registration for that page in local storage. It's a separate discussion on whether this is desireable, or if that should be cleared too.)

Scenario 3 - IdP one origin, RS separate origin

Alice makes a direct non-AJAX request to an image resource on Bob's pod

Alice: GET https://bob.podB.com/icon.gif

Browser makes a request, hits a 401, gets redirected to PodB's 'Select Provider' page, alice enters podA.com as her IDP, gets redirected to podA.com/login, then back to bob.podB.com/icon.gif.

Consent step: Currently, Solid skips the consent step. Classic decentralized login (OAuth2, Facebook Connect, etc) consent steps are generally encountered either a) The first time Alice's pod encounters bob's podB.com (maybe when Alice added Bob to her contacts), or b) Each time Alice logs into podB using her podA webid (this is more annoying to the user).

Post-login state:

a. PodA (IDP): Session cookie with alice's webid. "Logged in to PodA".
b. Bob's PodB (RP): Session cookie with alice's webid (the pod also has her ID token / credential, valid only for itself). "Logged in to PodB".

To Logout (again, since this is a raw image), Alice will have to visit bob.podA.com/logout directly (type it into the browser).

Post-logout state:

a. PodB (RP): Empty session cookie. Logged out of PodB.
b. PodA (IDP): Still logged in to PodA, so, session cookie with Alice's webid.

In this scenario, currently, Alice would have to separately visit her own pod's podA.com/logout endpoint to also log out of her pod.

OpenID Connect specs make provision for also optionally logging out of "upstream" IDPs (meaning, PodB would remember PodA's /logout endpoint, and would call it after it logged out Alice from itself).
But: one, we don't have it implemented (though we could). And two, the UI and user expectation is unclear. Does Alice expect to log out both out of Bob's pod and her own pod?

Scenario 4 - IdP one origin, RP+RS on another origin

Alice visits an App hosted on Bob's pod, clicks Login

Here, Alice visits some SPA type app (like Mashlib/Tabulator) which is hosted on Bob's pod podB.com, and she is not logged in anywhere.

Alice: GET https://bob.podB.com/meetings/one.ttl.

The app gets served up (wrapping the RDF resource). She clicks the app's Login button (powered by the auth client). The following things happen:

1. The RP App (bob's Mashlib) looks to see if it already has a user session for Alice in localStorage, sees that it doesn't, and opens a Login popup.
2. Alice selects her IDP (podA.com), gets redirected (inside the popup), logs in to her pod, gets redirected back to bob's pod, the window closes.
3. The RP App (mashlib) stores Alice's user session token in localStorage for origin bob.podB.com.

Post-Login state:

a. IDP (PodA): Session cookie with alice's webid. "Logged in to PodA"
b. RP (Mashlib): Client reg + user session in localStorage for origin bob.podB.com. "Logged in to App"

Notice that the actual Resource Server, Pod B, doesn't know about Alice yet! However, the first time the App makes a REST request to Bob's pod (using a credential token in the header), Alice will get a session cookie with origin *.pobB.com, so she will also be "Logged in to Pod B". (Since the App is hosted on same origin as the pod).

To Logout, Alice clicks the App's Logout button. Following happens:

1. (Client) App clears Alice's session token from localStorage for origin bob.podB.com. "Logged out of App".
2. (Client) App also sends a REST request to Alice's IdP's end session endpoint, so, alice.podA.com/logout.
3. (IdP/PodA) Clears Alice's webid from her session cookie. So, now "Logged out of IdP / PodA".
4. (RS/PodB) The App does not know about Bob's pod, however, so, "Still logged in to Bob's Pod" (until the session expires).

Open Question 1: How should the App know to notify Pod B of logout? Alice's pod A could keep track of "downstream client apps/RPs" (again, the spec provides for it), but there's no good way for it to know about downstream Resource Servers -- it doesn't know that the App communicated with Bob's pod at all.

Perhaps the problem is that PodB created a session cookie for Alice, even though she has an external WebID (not hosted on Bob's pod)? (Notice that, given the current semantics and security model, this is still legitimate because the Origin: of the App (that made an AJAX request to Bob's pod) was still the same as the pod, so the cookie would have been created). So we could change it so that cookies are given not only for local-origin calls, but also for local WebIDs. (Though that has other usability implications).

Open Question 2: Does Alice expect to Logout from both the App and her own PodA, when she hits the logout button?
That's what the current behavior is.

Scenario 5 - IdP+RS one origin, RP second origin

Alice logs into an App on Bob's pod, App fetches a resource on her own PodA

What if Alice logs in to the same app as in Scenario 4, a Mashlib based app on Bob's pod, but only fetches resources from her own podA? (This is also the same scenario as if the RP App was hosted on a non-pod origin, e.g. AWS or Github.io).

Post-login state: a) Logged in to App (app has token), b) Logged in to IdP (PodA)

Now the App can make REST requests to Alice's own pod, but only using the app's token, not her own session cookie, since we disallow external origins to use session cookies.

If she clicks the Logout button, again, the App a) clears token from localStorage "Logged out of App", and b) Makes a request to podA.com/logout, which clears her session cookie to her PodA, so "Logged out of PodA".

Ok, no problem, all logged out.

Scenario 6 - IdP one origin, RP second origin, switching WebIDs

Alice visits App on Bob's pod, clicks Login, then needs to switch WebIDs (so, Logout then Login again)

OK, so, now we come to the scenario that started this conversation. If Alice is visiting Bob's pod, logs in, then wants to switch her WebID (by logging out & logging back in with something different), what should happen?

So, part of that depends on which WebIDs she is switching between. That means we have two sub-scenarios.

Scenario 6A: App on Bob's pod, switching from alice.podA.com/#me to OTHERalice.podA.com#me (new WebID hosted by SAME IdP as before).

Alice logs to RP App hosted on Bob's pod as her usual alice.podA.com/#me. Then wants to switch to a different WebID of hers. So, she clicks Logout.

Post-Logout state: Logged out from App, Logged out from PodA, still logged into PodB if App made any requests to PodB.

To switch/relogin: She clicks Login again. Gets a popup, selects PodA as provider, has to log in to her own PodA again, since she logged out of it.

Post-relogin state: PodA has session cookie for new WebID, App has localStorage credential for new WebID, OTHERalice.etc.., PodB has session cookie for old WebID.

(Potential) Problem: NOW, the App makes requests to Bob's PodB, they have 2 credentials: a) an Authorization: Bearer ... header with the token for new WebID, and b) A browser Cookie for domain *.podB.com with the OLD WebID.

Open Question 3: In the Solid Server auth handlers, do cookie session WebIDs take precedence over token credential WebIDs? (If so, that needs to be switched around.)

Scenario 6B: App on Bob's pod, switching from alice.podA.com/#me to something.podB.com/#me (the new WebID is on Pod B).

Logs in as alice.podA.com/#me, same post-login state as before. Clicks Logout. Same situation as before - logged out of PodA, logged out of App, but still logged into PodB as old webid via cookie.

Problem: When she goes to re-login, clicks the Login button, gets Select Provider popup, now selects PodB, and gets redirected to PodB's /authorize endpoint. However, since she still has the PodB session cookie, the /authorize endpoint (correctly) skips the login form, and returns her to the original App, logged in as the old WebID.

Solution: Same as the solution to Question 2; probably need to disallow session cookies for externally-hosted WebIDs.

Scenario 7 - IdP one origin, RP second origin, RS third origin (or more)

Alice visits an App on Bob's pod, clicks Login, App fetches a resource from Cindy's pod

Hoooo doggie, this is why we got into this decentralization shindig in the first place, right? Decentralized Twitter, log in once and fetch messages from countless other domains!

Alice visits bob.podB.com/cimba2-twitter-clone/ app. Logs in as alice.podA.com/#me.

And then the App starts fetching resources from Pod C, cindy.com! (And likely other origins, as well).

Post-Login (and post-fetch) state:

a. Logged into PodA (via session cookie to her home pod)
b. Logged into App (via ID token credential from PodA), stored in localStorage.
c. (for completeness) Cached Proof of Possession tokens for each intended resource server (cindy.com, etc), in memory (in a JS object), will go away once user navigates away from page. Not logged in, though!

Notice that there's no session cookies for cindy.com or any other external resource servers (since, if they're running Solid servers, they disallow cookies for external domains).

So how does Logout work? Same as in Scenario 4.
Alice clicks Logout, App auth client a) clears localStorage of Alice's session ID token from PodA, b) sends /logout request to Alice's home pod.

So now she's logged out of everywhere.

Open Question 4: (Need to make sure) Do we cache PoP tokens in the auth client memory (not in local storage)? And if so, do we clear that cache on logout?

Scenario 8 - SSO ("Single Sign-off")

Alice is logged in to multiple apps, in different tabs, as alice.podA.com/#me

What, there's more? Awww yess, we haven't even talked about multi-tab (or multi-window) Single Sign-On / Sign-Off.

The idea being, if Alice is logged in as herself, in multiple tabs (on different apps, multiple origins), what should happen on Logout? Let's go through the combinations.

8a - Logged into podA, App1, clicks Logout on App1

This is the same as our Scenario 2, so - should she expect to be logged out of both podA and App1? Yes. (So, that's fine, that's the current expected behavior).

8b - Logged into podA, App1, clicks Logout ON HER POD

Ah, but what if she's still logged into App1 (did not click the Logout button), but she visits (say, manually) her pod's /logout endpoint?

The following things currently happen:

1. Her Pod clears her webid from session cookie. (No longer logged into Pod A).
2. She's still logged in to App1 (since her token is in localStorage at App1's origin). Which means that App1 will still be able to make REST requests until the token expires. Still plausibly fine/expected.
3. If App1 is hosted on PodA, and makes a REST request to PodA, the pod will (re)start her session via cookie, with the same WebID. Slightly counter-intuitive -- though she logged out of the pod, her app "logged her back in".

8c - Logged into podA, App1 and App2 (different tabs)

So, let's say Alice is using two different apps in two different tabs, same WebID. If she clicks the Logout button on one app, should she also be logged out of the other app? (In addition to the current behavior of being logged out of the pod).

This is what's known as "Single Sign-Off" -- you Logout once, and you're logged out of all RP client apps that are using that WebID. In the OIDC specs (and similar methods), this is done by keeping a WebSocket backchannel open, and the IdP (Alice's pod) notifies all the apps when any of them log out.

We haven't implemented that part of the spec yet. Should we?

Similarly (as with 8b), if Alice logs out of her PodA, should all the other tabs & apps that are using that WebID also be notified (and be logged out)?

[RubenVerborgh]

Asking @kidehen.

[RubenVerborgh]

So, I'm not a security expert, but here are my two cents.

It seems that cookies act as the mechanism to authenticate non-AJAX requests, and bearer tokens for AJAX requests. The existence of two mechanisms introduces questions such as precedence.

Let's try to only have one at the same time. What I propose is that:

• we use the Bearer token to contact a server for the first time necessary (i.e., after a 401)
• this results in a session cookie
• from then on, the session cookie is the only thing that counts
• logout means removing the cookie, not just emptying it; that way, the client can easily interpret the cookie (if it's [not] there, we are [not] logged in).

Additionally, we need much more introspection in solid-auth-client. I want to be able to ask it, at any moment, which server has acted as IDP and with which servers I'm currently logged in.

[kidehen]

@dmitrizagidulin and @RubenVerborgh ,

All of your scenarios ultimately boil down to the fact that an OIDC-pod works best when the following holds true:

1. User has the notion of a canonical WebID
2. User is happy for an application to surreptitiously handle identity credentials tokenization and authentication -- because that's the nature of the protocol in use i.e., OIDC (with or without the WebID addition).

You may or may not know that we have an application call the OpenLink Structured Data Bot (OSDB) that is built using node.js and operates as a solid client. Anyway, I've asked the development lead of this particular project to contribute a response to this thread.

[dmitrizagidulin]

@kidehen No! :) That's not what it boils down to. What it "boils down to" is "Hey logging out is actually complicated in a decentralized environment. So we need to outline the scenarios, and make sure we've thought it through carefully." And all authn methods will need to deal with these scenarios (including the ones that you're promoting). Because part of the complication (as @RubenVerborgh points out) is that servers generate session cookies in addition to any other authn method. So WebID-TLS sessions will also generate those same cookies, and have the same difficulties in logging out.

1. User has the notion of a canonical WebID

No. Switching WebIDs is definitely supported, that's the intention. There's a couple of issues (mostly having to do with cookies / auth precedence) in Scenario 6, but those will be fixed.

2. User is happy for an application to surreptitiously handle identity credentials

Ok, what kind of fear-mongering language is that? :) Yes, software components do handle credentials in this setup, as they do in all authentication methods. That's what they're for.

[kidehen]

@dmitrizagidulin ,

I'll rephrase, at the current time, OIDC-pod deployments work as I've described. If not, then why is it that I can only toggle WebIDs by manually cleaning out prior session data via my browser's inspector?

I am hoping OIDC-pod deployment can work better, but I am describing the current state of affairs.

Should my characterization be inaccurate, then you must be able to prove that via an existing instance of a pod, right?

As for:

No. Switching WebIDs is definitely supported, that's the intention. There's a couple of issues (mostly having to do with cookies / auth precedence) in Scenario 6, but those will be fixed.

I am assuming there is an issue regarding the fix then? And once resolved my current assessment will be corrected etc..

[dmitrizagidulin]

@kidehen Wait, let's consider the context of this discussion.

This here is an issue describing a bug, namely that WebID switching is not working. My comment with the various scenarios was just an attempt to understand why it's not working, and to talk about what the fixes should be. Your summarize that discussion, somewhat dismissively, as "what it boils down to is that you can't switch WebIDs". Well yes.. that's what this issue is about. It's a bug discussion.

If you're implying that the protocol doesn't allow switching WebIDs, that's not the case. There's a couple implementation issues, though, that need to be fixed.

[cblakeley]

Hello all, I'm the development lead on OpenLink's OSDB project (https://osdb.openlinksw.com). @kidehen asked me to comment on this thread.

If I understand correctly, the central issues which triggered this thread are:

• "If Alice is visiting Bob's pod, logs in, then wants to switch her WebID (by logging out & logging back in with something different), what should happen?".
• "logging out is actually complicated in a decentralized environment"

My exposure to Solid has been limited to using it as an OIDC IdP for OSDB. I've had some difficulties with it in this regard, so I wanted to relay my impressions of what's caused the difficulties, albeit from the point of view of Solid as a black box with no knowledge of the code base. Please correct me if I'm wrong.

Short version

When using OSDB as an RP with Solid as the OP, it appears:

• Solid cookies are not session cookies, but persistent cookies. I think they should be session cookies.
• Solid doesn't support RP-initiated logout
• Solid doesn't provide an indication in the browser that a user is logged in, whereas Google displays a 'badge'; so a user knows they're logged into the Google IdP even when they open a new page/tab. The 'badge' makes it clear the user has to manually logout of Google.

Long version

FWIW, below is a description of how OSDB handles login/logout across both WebID and OIDC.

OSDB essentially handles two type of login 1) WebID 2) OIDC (including WebID-OIDC). Both types of login result in the end-user receiving a session cookie, osdb.sid, which is an opaque key mapping to a session object in the OSDB server. The server-side session object holds, amongst other things, the user's NetID. The NetID may be either:
a) WebID, if the user logged in using WebID-TLS(+delegation), or
b) the users profile URL (aka a NetID) if logged in through a 3rd party OIDC IdP, e.g. via Google, the NetID might be https://plus.google.com/+CarlBlakeley

OSDB ACLs should grant access based on both WebIDs or NetIDs.

In order to change their current OSDB login, a user obviously has to logout then login again. Logging out clears the osdb.sid session cookie and the server-side session object. This is all that needs be done for WebID-TLS logins (with or without delegation). However for OIDC logins there's more to consider.

OIDC Login/Logout Handling in OSDB

OSDB acts as the RP. Authorization flow is used. As part of the authentication process, OIDC provides an access token which can be used to access the end-users profile and selected data (depending on the scopes requested), and also to access protected APIs belonging to the IdP service. The user's profile URL from the authenticating IdP acts as a NetID as already explained.

All IdP (OP) registrations are held on the OSDB server, rather than in browser local storage (as is the case with OIDC implicit flow). The OSDB server maintains a server-side equivalent of browser local storage, oidc-rp-storage. oidc-rp-storage consists of multiple 'hives', one per authenticated end-user. Each 'hive' contains essentially the same data as that maintained by Solid in browser local storage, though I've made modifications.

When an OSDB end-user logs in through OIDC (or WebID-OIDC), a hive is created. The hive holds both the RP registration (under key 'rpConfig') and the user's session data (under key 'session'). The session data includes a clientId, an idToken and an accessToken. When the user logs out, the session data is destroyed, but the RP registration is retained. In order to link an end-user to their hive, they receive a second cookie, osdb.storage_id. This is a persistent cookie, rather than a session cookie. osdb_storage_id is also saved to browser local storage so it can be recreated if the persistent cookie is lost or destroyed for some reason.

As a side effect of logging into OSDB using OIDC, the end-user is also logged into the OP and typically receives a session cookie from the OP. This is the case with both Google and Solid. When the user logs out of the OSDB (RP), OSDB takes no action to log them out of the OP, so the OP session cookie remains. The end-user is left to log themself out of the OP if required. In the case of Google, the browser makes it apparent that the user is still logged in by displaying a user 'badge'. I'm not sure this is the case with Solid.

It also appeared to me that Solid was creating a persistent cookie rather than a session cookie. The only way I was able to change logins with Solid was by manually deleting the cookie after logging out of my first login - the act of logging out didn't destroy the cookie. From the code at the time, I think property cookie.maxAge needs removing to make connect.sid a session cookie, rather than a persistent cookie:
https://github.com/OpenLinkSoftware/node-solid-server/blob/08bea82dd9f010278f34d6d7a030efd507a5df02/lib/create-app.js#L234

The question of whether the RP should, when an end-user logs out of OSDB, take steps to also log them out of the OP is unresolved at present. The OIDC session management spec (http://openid.net/specs/openid-connect-session-1_0.html) includes features for handling logout, including RP-initiated logout. The nodejs oidc-rp library used by OSDB (https://www.npmjs.com/package/@trust/oidc-rp) claims to support RP-initiated logout and from looking at the code, appears to do so. But I'm not sure that Solid, as an OP, supports this feature. Google doesn't, so the end-user is responsible for manually logging themself out of the OP, after logging out of OSDB; or in Solid's case, manually destroying the 'sticky' session cookie.

[kidehen]

@dmitrizagidulin ,

Re #20 (comment), I am not trying to be dismissive. Instead, I am trying to be succinct regarding what the current issue is.

Please understand, I simply want to be able to achieve the following:

1. Identify the problem based on how it manifests
2. Align problem with an issue that seeks to fix said problem.

Thus, at this point in time, is it accurate to assume the following:

[1] OIDC-mode pods require users to manually login and out in situations where multiple WebIDs are involved?

[2] This issue can be fixed, but there are some issues regarding clarity about the nature and scope of a logout.

I am sure we can get to a point of clarity here :)

[dmitrizagidulin]

Thanks @cblakeley, you bring up some great discussion points. Let's take em slightly out of order.

Solid doesn't support RP-initiated logout

It should, definitely file a bug if that's not working. Like you mentioned the RP client supports RP-initiated logout, as far as I know the current auth client invokes it on logout, and on the OP/server side, node-solid-server processes it when the client hits the /logout endpoint -- see clearUserSession() code here.

Solid doesn't provide an indication in the browser that a user is logged in, whereas Google displays a 'badge'; so a user knows they're logged into the Google IdP even when they open a new page/tab. The 'badge' makes it clear the user has to manually logout of Google.

That's a great point. I think Tim's Mashlib (and solid-ui lib specifically) are meant to serve as a set of reusable components, for just this sort of purpose. But I think we need two more action items here: 1) File an issue on mashlib or solid-ui to display a user's logged in status more clearly. and 2) If possible, implement and provide a lightweight badge (like Google and Facebook do) for app developers to be able to drop in, that would denote user session status.

[dmitrizagidulin]

@cblakeley

Solid cookies are not session cookies, but persistent cookies. I think they should be session cookies.

This one's tough (in terms of being a UI/UX decision, it's easy to switch to a session cookie implementation wise).

As a user, doesn't it drive you crazy when your login cookies aren't persisted? I know that on iOS, on mobile Safari, it drives me nuts that I have to re-login everywhere constantly despite having clicked 'Remember me' checkbox, because that browser forces session cookies and cookie expiration.

Like.. I don't know if Solid end users would like session cookies (instead of persistent cookies) very much.

Can you say more about why you'd prefer session cookies? (We could probably make it a config option, for server operators, to switch between persistent cookies vs session cookies, but I'm having trouble picturing the advantage of the latter.)

the act of logging out didn't destroy the cookie

True, the current Solid/Express behavior is to just always set a cookie on every request. So, logging out doesn't delete the cookie, but it clears the user's WebID from that cookie's session store.
Which means, logging out should have ended your user session without deleting the cookie (and as far as I tested yesterday, that part works). If it doesn't, let's file an issue. (@RubenVerborgh - I haven't forgotten about your recent comment regarding cookies, will reply to it in a bit).

[dmitrizagidulin]

@cblakeley

The server-side session object holds, amongst other things, the user's NetID.

That's really cool! I've wanted to add that functionality for a while - to give the option for users to log in with, say, their Google account (in addition to TLS, username+pw, etc). And to integrate this notion of external NetIDs into the ACL system. So, that's really cool that your project has that working! (It's definitely on the medium-term roadmap, personally.)

The OSDB server maintains a server-side equivalent of browser local storage, oidc-rp-storage. oidc-rp-storage consists of multiple 'hives', one per authenticated end-user. ... The hive holds both the RP registration (under key 'rpConfig') and the user's session data (under key 'session').

Nice. Solid-server currently does something similar, using the multi-rp-client library. I'm actually in the process of folding that functionality into the oidc-rp client itself, so that everybody doesn't have to roll their own (like what you did with oidc-rp-storage and I did with multi-rp-client).