solid / specification

Solid Technical Reports
https://solidproject.org/TR/
MIT License
488 stars 45 forks source link

AuthN/AuthZ when accessing protected resource directly with a web browser #382

Open elf-pavlik opened 2 years ago

elf-pavlik commented 2 years ago

We have a related issue https://github.com/solid/solid-oidc/issues/31

We discussed it again today during AuthN meeting and decided that we should circulate it here first. /cc @acoburn

We need to clarify if we want to support direct access with a web browser, so the resource URL would appear in the address bar. When it comes to Solid-OIDC in particular, this would require Solid Storage to implement Solid-OIDC client. Storage in this particular case would play the role of OAuth Client and not OAuth Resource Server (no Access Token comes into play, just the ID Token).

Among various nuances of this scenario, we would need to clarify various security considerations, especially that Storage acting as OAuth Client would most likely use cookies to establish session in the web browser. For example, other clients running in a browser shouldn't be able to circumvent their restriction by using that cookie and getting access as if there were the storage itself.

Once we clarify general requirements motivated by this use case, we will also need to decide where we should specify that Solid Storage needs to implement Solid-OIDC Client, besides implementing Solid-OIDC Resource Server.

I included AuthZ in the title since we will need to include it as well. We currently move towards having the default no access for any client unless explicitly allowed. If storage acts as the client we should also consider if it needs explicit authorization or we will rely on implicit authorization if storage itself acts as the OAuth client (Solid-OIDC).

elf-pavlik commented 2 years ago

Based on a conversation in https://github.com/solid/solid-oidc/issues/31 we lean towards NOT requiring storage to support directly accessing protected resources with a web browser.

elf-pavlik commented 2 years ago

@RubenVerborgh I'm afraid I didn't fully get what do you suggest.

Given https://storage.example/some-protected-resource in solid storage, when someone tries to access it directly with a web browser, then storage replies with 401 Unauthenticated and MAY include solid application in the body?

I recall fiddling with Service Workers in https://github.com/solid/solid/issues/143 Possibly the application provided by the storage would take care of installing a service worker and authenticating, further access would be able to rely on that service worker. It's been a while and I haven't used service workers lately 😐

Anyways if in this issue we can agree that supporting this use case would be just a MAY, the details of how this could be done could simmer somewhere on the back burner.