But if bbb tries to access the https://aaa.solidcommunity.net/private/test.ttl with an app, e.g. https://penny.vincenttunru.com, or with the app we’re developing; they will receive 403 User Unauthorized error. (the XHR request trying to fetch the document includes header Authorization: DPoP eyJhbGciOiJSUzI1NiIsImtpZCI6Ikpx... , so i suppose the authorization is set up correctly)
Now, why is this happening? If somebody shared their data with me, i want to be able to access it with an app of my choice.
do we need some special kind of authorization for an app when accessing someone else’s data with the app? (fetching seems to fail even when aaa sets the apps as trusted apps with Read permission, i.e. :me acl:trustedApp [ acl:mode acl:Read; acl:origin <https://app.domain.example.com> ].)
is there some issue with the inrupt JavaScript libraries? (both failing apps use @inrupt/solid-client and @inrupt/solid-client-authn-browser to authenticate and access data.
is there some incompatibility between Node Solid Server authentication/authorization and way the inrupt libraries handle authentication/authorization? (please note that the mentioned users have solidcommunity.net pods, which run Node Solid Server.)
Hmm, as far as I can see bbb should indeed not have any trouble accessing that resource. Are you sure that it’s bbb that’s signed in when you visit the resource directly? Could you try opening a private browsing window, visiting the resource there and then signing in as bbb? (Just in case aaa’s session was still active or something.)
The user experience of signing in is a current topic of discussion and it does seem useful to discuss what is expected in the scenario of using an app to access data of other users/other pods.
My understanding is that as long as the (web) app is not refreshed, it should be possible to access data from multiple pods within the same session without logging in again. Depending on the length of time between requests, this may require use of the refresh token.
If the app is refreshed, then new authentication should be required but depending on the identity provider (IDP) the authentication session will be remembered for a certain time (usually via a cookie) and it won’t be necessary to enter login details again.
If instead of using a single app, resources are accessed directly through the pod’s internal browser, then separate logins would indeed be required for each pod, again possibly with credentials remembered by the IDP.
I.e. the access token is held by the app not by the browser.
For logging out, we have to distinguish between logging out from an app vs from the IDP.
For a web app, as the access token is lost on refresh, it’s basically logged out every time the app is closed. It can look like it’s still logged in if the IDP uses a cookie, i.e. an app is automatically logged into if the IDP is logged into and has a record that the app is trusted.
Logging out from the IDP then has the appearance of logging out from all apps in that browser.
My understanding is that the pod checks with the IDP on every request so no logging out is needed there.
Of course it’s also possible for an app to have its own separate persistent store for an access token, in which case it would still need a separate “log out” to forget the access token it has.
I’m not yet sure if or how revocation of access and refresh token works with the current servers.
I.e. logging out in principle is a separate concept for the app and IDP.
If anybody else notices an error, please to correct me!
We are currently experiencing the same issue on Node Solid Servers
. If somebody shared their data with me, i want to be able to access it with an app of my choice.
It shouldn’t be the case that each time I start using a new application that accesses the same data that another user has shared with me, that person needs to add that new application to the acl.
An example:
I share a file or folder with “https://person_a_web.id”
If the person just goes to the file or folder using a web browser, the person can indeed see and access the information.
If, however, that person uses an application (such as penny), the person can’t access that same information.
I’m a bit surprised we only see this issue popping up, so maybe there was an update?
So something to note: @inrupt/solid-client-authn-browser (and also -node) don’t actually support logging out of the identity provider (OIDC server), all they do is clear the stored data from localstorage/sessionstorage
If you actually want to log out completely, you’ve gotta use the end_session_endpoint (or whatever it is, I can’t remember off top of head) from the OIDC configuration document.
It’s something that does eventually need to be supported in that SDK, though.
