I’m developing a React web application that connects to a Solid POD using the @inrupt/solid-client-authn-browser library for user authentication. After the user is authenticated, I have a backend server that needs to access the user’s data in the POD, but without requiring additional interaction from the user.
My question is: if the frontend sends the JWT issued by @inrupt/solid-client-authn-browser to the backend, can the backend use it to access the POD’s data? Alternatively, is there any other authentication method that allows a backend server to access user data without additional user interaction?
I’m confused about this interaction. Is there a reason you cannot send the request from the React application after authentication? Is there a specific reason you need the user to authorize and then pass the authentication to the backend?
Inrupt supports static client registration through their servers, which a web server can use to act on behalf of a client and perform action against their protected resources. This is also supported in a slightly different way in CSS, but both are capable.
@inrupt/solid-client-authn-node (i.e. not -browser) was designed specifically for the use case of a backend accessing a Pod.
There are two ways of approaching that. The easiest, but not necessarily most transparent, method is to simply route all requests through the backend, I no longer using SCAB.
The other way is giving your backend its own WebID, and then in the client giving that WebID access to the Resources it needs.
The two previous answers are accurate: we have two separate authentication libraries, one for pure frontend apps (the one you are using) and one for backend apps (the one Vincent mentioned). If you want to be able to perform action on behalf of the user without them being present (i.e. without their browser being open), you might be interested in the Backend-For-Frontend pattern. Essentially, your in-browser webapp would become a light client talking to a dedicated backend API, and the Solid authentication part happens on the backend (you can manage frontend session any way you see fit, e.g. using a traditional cookie, since that would likely be same-origin). That’s the first approach Vincent described, and in this case the app would be acting on behalf of its user (this can be referred to as a “piloted app”). In the second approach Vincent describes, the backend is acting on its own behalf, regardless of the end user (which has an impact on permissions). This can be referred to as an “autonomous app”.
To specifically respond to your original question:
No, because of a protection in place called DPoP: the in-browser client signs its requests with a private key that is never exchanged over the wire. This prevents any actor grabbing the token from being able to reuse it to issue additional requests.