Node-solid-server: Unified mechanism for maintaining login state across client and server

[RubenVerborgh]

Right now, users need to log in once on the server (session cookie) and once on the client (so AJAX requests can be signed through OIDC).

We should evidently change this into one login. Maybe having establishing server-side authentication state (in the form of a [session] cookie) isn't necessary at all.

[dmitrizagidulin]

Maybe logging in onto the server isn't necessary at all.

It's needed just for two reasons - to request resources directly from the server via browser (like images), but more importantly, to identify the user to the /authorize endpoint, as we discussed during the previous meeting.

[RubenVerborgh]

but more importantly, to identify the user to the /authorize endpoint, as we discussed during the previous meeting.

Would it be an option to call the /authorize endpoint with an AJAX call that has the Authorization header set?

[melvincarvalho]

@RubenVerborgh do you have an example of what would be set in the Authorization header?

[RubenVerborgh]

The regular OIDC bearer token as for scripted OIDC requests.

Authorization: Bearer eyJhbGciOiJSUzI1NiJ9.ey…7iPAbNZlx-xccMCIfMu4oNJuLMWaw

[melvincarvalho]

@RubenVerborgh thanks!

I agree with @dmitrizagidulin here. The modular nature of solid requires, both scenarios.

In the longer term you could imagine multiple different user agents (browser, mobile, desktop, native app) with multiple login strategies to a server. I dont think the server login can go away, in the short term (ie for 5.0.0).

I may have missed some points as I'm not as close to the identity / authn / authz side as you guys. But I welcome proposals or extra detail.

[RubenVerborgh]

The modular nature of solid requires, both scenarios.

Hi @melvincarvalho, can you be very specific here? There is a difference between “we require server-side login state management” versus “we require browser-based access”.

In the longer term you could imagine multiple different user agents (browser, mobile, desktop, native app) with multiple login strategies to a server.

The only user agent that uses “server login” (to be understood as “cookie-based session management”) are non-scripted browser interactions; none of the others require a server-based login whatsoever, nor will they ever.

[melvincarvalho]

There is a difference between “we require server-side login state management” versus “we require browser-based access”

Solid is a very modular system, with commodity servers, and a range of user agents. These can be browsers, servers, robots, native apps and more. Each user agent will have different capabilities and restrictions. e.g. an electron app might be able to have better key management than a mainstream browser (for example safe browser, which has implemented webid switching, including per tab webids)

A cookie is one authentication and identification strategy. As is PKI, most commonly with WebID-TLS, OIDC, and WebID-RSA.

Similarly servers, when used to access solid, will have different auth capabilities and strategies. Most simply using curl with a certificate, and more recently with your most excellent solid-cli library.

Solid is therefore a rich architecture of servers and user agents (much like the web), with many possible auth strategies (shared secret, PKI, hybrid).

All that said, I am still learning on this front, and will gladly accept guidance. It seems to me that this could be specified a bit more before diving in to the 5.0.0 milestone (which may be for a very good reaqson, im unaware). Hope that helps!

[RubenVerborgh]

Discussed with @dmitrizagidulin. The problem root problem is that there is no synchronization of the state the being logged between on the server and the client. Doing this is currently impossible because server-side login is indicated with an opaque cookie.

Broadly speaking, there are three kinds of solutions

a. get rid of the cookie (leaves the open question of how to transition from /login to /authorize, and how to make native browser requests)
b. make the cookie transparent, so the client can read it and adjust its own logged-in status
c. implement a /userinfo endpoint, so the client can verify the user's status

Let's discuss these options below.

[melvincarvalho]

@RubenVerborgh thanks again, for clarification!

That makes sense. Clearly syncing is important, for the user experience. Will try and consider this in more detail. Just want to flag that there is not only the HTTP part, but the websocket part, where the server maintains persistent sessions for a user.

[RubenVerborgh]

Related to this issue is #747. Clarified the title of this issue to differentiate.

[dmitrizagidulin]

@RubenVerborgh Great summary, thanks. So my thoughts are as follows: option a) is not really viable (in terms of, we need to make native requests etc).

Which means that it's a choice between b) and c), and the main difference is, really, engineering effort required to implement. From what I've been able to see at a glance, when looking at the express session cookie repos (and the various session plugins), option c) would be easier to implement. But I could be missing something obvious. :)

[RubenVerborgh]

What bothers me about c) is that it introduces a third mechanism to synchronize the two existing mechanisms of cookies and tokens, whereas b) essentially tries to unify those two.

In any case, I think that #747 is the priority here; signing in on the client also establishes the server session, but not the other way round. So just doing that already gets us some of the synchronization we need.