Use an app to access data of other user: 403 User Unauthorized

Hello. I have stumbled upon the following issue:

Let’s say there are two users https://aaa.solidcommunity.net/profile/card#me (aaa), and https://bbb.solidcommunity.net/profile/card#me (bbb).
User aaa makes a private document https://aaa.solidcommunity.net/private/test.ttl and shares it with bbb (i.e. no public sharing).
User bbb goes to https://aaa.solidcommunity.net/private/test.ttl. If they’re signed in, they’ll see the document. if they’re signed out, they won’t see the document.

So far so good.

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.)

Thanks for any ideas!

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.)

Did you set the trusted app in user bbb’s profile as well?

@Vincent @aveltens Thank you for your replies! It was reassuring when you confirmed this should work as i expected.

Indeed, I can’t reproduce the issue right now. Things work as expected (minus the pain of signing in and out consistently).

So the issue rather seems to be How to properly sign out of and into a solid account. But that’s out of scope of this thread.

Thank you! :orange_heart: :fallen_leaf: :jack_o_lantern:

2 Likes

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!

1 Like

I wouldn’t have thought this was required?
Isn’t the trusted app checked by the IDP, not the pod?

Otherwise if you want to use a new app then you need permission from each pod owner first?

Edit: Oops, yes, it’s definitely needed for user BBB because they’re the one making a request. It shouldn’t be needed for the pod owner aaa

Yes exactly. Is it needed for both?!

1 Like