Rethink authentication configuration

[RubenVerborgh]

Right now, the server supports two different auth modes, confusingly named auth: "tls" and auth: "oidc", even though that doesn't cover exactly what they do. The main problem is that this one setting gives the impression that both methods are mutually exclusive, whereas they are not.

Discussions such as #667, #671, nodeSolidServer/solid-auth-client#44, solid/solid#138, nodeSolidServer/oidc-auth-manager#20 show that there is a need for more clarity, and a better configuration option.

This issue tracks general progress and will act as a tracker for multiple sub-issues.
Here are the steps we need to take in my opinion:

• Have one single contract for the entire node-solid-server to track a) the WebID of the logged-in agent b) the method through which that agents has logged in
• Document the above contract
• Ensure that “ask for a client certificate on every resource (WebID-TLS)” can be enabled and disabled independently of other features
• Ensure that “act as an OIDC identity provider” can be enabled and disabled independently of other features
• Ensure that “log in with OIDC through username/password” can be enabled and disabled independently of other features
• Ensure that “log in with OIDC through client certificates (WebID-TLS)” can be enabled and disabled independently of other features
• Ensure that “accept bearer tokens” can be enabled and disabled independently of other features
• Examine whether we want to always translate successful logins into an Express cookie-based session
• Examine whether we want to allow turning on or off cookie-based sessions
• Create a configuration section that allows to enable and disable all of the above options independently
• Update the init generator to create the right config
• Remove the old auth config section

Feedback welcome.

[elf-pavlik]

I see that currently those 3 mechanisms allow authenticated requests:

• client certificates
• bearer tokens
• cookies

Few questions come to my mind:

• which use cases require use of cookies and can not use barer tokens instead?
• in which order those mechanisms apply when server expects authenticated request?
• when one mechanism gets exchanged for another one, for example
  • cookie gets set based on client cert
  • cookie gets set based on bearer token
  • bearer token gets issued based on client cert

[RubenVerborgh]

Remark by @timbl that we should differentiate between AJAX requests and regular browser requests. For the latter, cookie-based sessions are very useful.

[elf-pavlik]

I understand that we can rely on bearer token only when we make requests with Fetch API in javascript. Regular browser requests only support client certificates and cookies.

I think in most scenarios RDF Sources would get requested with Fetch API, but Non-RDF Sources which IRIs get used directly as values of src attribute in HTML elements would end up as regular requests.
In that case, WebID-TLS could trigger cert selection popup if media resource embedded in the page requires it. How WebID-OICD supposed to handle those cases if browser doesn't have active cookie session with the origin of that embedded media resource?

I'd also like to check if Service Worker can intercept regular browser requests for media resources and give control back to developer over how requests are performed, possibly also to include bearer token or request Federated Credential solid/solid#142 if needed for WebID-OICD flow.

[RubenVerborgh]

How WebID-OICD supposed to handle those cases if browser doesn't have active cookie session with the origin of that embedded media resource?

We'd need some scripting to detect this and help us with that.

I'd also like to check if Service Worker can intercept regular browser requests for media resources

That might be possible to a certain extent! I am interested in porting solid-auth-client to a worker, so I can run it in the background (as we currently do for our query client, for instance).

[elf-pavlik]

We'd need some scripting to detect this and help us with that.

I started separated issue to discuss Service Workers including possibility of using them in such scenarios. solid/solid#143

[elf-pavlik]

solid/solid#142 (comment)

@dmitrizagidulin But no session is created (and no cookie is generated) when the RP makes a request to some third Resource Server. So, when I sign into a distributed Twitter type app which fetches messages from a dozen different resource servers, I only have a session with my WebID's IDP, and the app itself. But not with any of those resource servers.

Based on above, server not acting as IdP (OICD Issuer) would never use cookies. Given that, I think for general role of Resource Server (dataset origin) we should never rely on cookie based sessions and for authenticated request only use:

• client certificates
• bearer tokens

This way it would not matter if client interacts with datasets on same origin as user's IdP or datasets on all other origins.

[melvincarvalho]

Thanks for putting this together!

Will there also be a sub issue related to the initialization of a server for the first time. ie running

bin/solid init

Possibly some of this will change too. Is it covered in an existing sub issue?

[RubenVerborgh]

@melvincarvalho Added to the list above