One-time / Short-span remote authenticated fetch?

This is a question related to [Solved] How to attest possession of a WebID (from arbitrary source)?, but with different focus.

In short: in JS, to fetch a Solid resource, how can I share the authenticated headers with a remote server, and let the remote server perform the request?

The usages are:

  1. The remote server can verify my identity (similar to the referenced post);
  2. The remote server can verify that I have permission to access the target resource.

What I understand so far

Based on my understanding, it looks like the following flow should work:

  1. The client obtains the authentication header to the target resource;
  2. The client sends a request to the relevant endpoint at the remote server, with payload/data containing the authentication header (and the link to the target resource if the remote server doesn’t know this beforehand);
  3. The remote server extracts the authentication header from payload/data, and attests WebID as stated in the linked post (through access-token-verifier);
  4. The remote server puts the header into HTTP request, and performs the request to the target resource.

If it indeed works based on the specification, how can I do Step 1 using any JS library (esp. @inrupt/solid-client-authn-browser)?
I know I can get a fetch object performing authenticated fetches, but there does not seem to be a function to obtain the relevant request header only?

1 Like

This is just after a quick thought but are you talking about verifiable credentials and/or access grants? I know ESS has a experimental features using them.

No. I’m talking about Solid-OIDC, I believe.
The assumption is that there has already been access rules set up, which should work correctly. But now I want to let an agent / remote server to access a particular resource that I have access to. There could be several reasons to do this, but the most appealing one to me is: the remote server knows that I have permission to a specific resource, as a means to verify my identity.

There could well be other ways to verify my identity, but this one has the benefit that the remote server does not need to know the list of all WebIDs they should permit – they will only know that “if this WebID is permitted or not”.

(Also added some additional information to the original post.)

1 Like

I believe right now the default with Solid-OIDC are the Authorization and DPoP headers, both of which are a dpop-bound jwt.

So the simplified workflow is a client prepares a JWT and sends it to the Authorization server which verifies the JWT and responds with an access token back to the client.

The client then takes this access token and attaches it in the Authorization header and looks like Authorization: DPoP access-token-string. The client then generates a DPoP token for the resource it wishes to access and sends it to the resource server as a DPoP header which looks like DPoP: resource-specific-jwt, who then validates the access token in the Authorization header and verifies the DPoP bound JWT for the specific resource.

Full DPoP diagram here

In theory your idea would work, as the resource server only needs to validate that the public key of the access token and the public key of the resource-specific DPoP token need to match. The remote server would simply have to perform that same check if I’m right, before forwarding the headers to the actual resource server.

A couple issues though could be in the claims, especially the issued at time and expiry time, if the request takes too long. Another issue could be a URL validation, if you create a token from client x and send from server y - the resource server may check for discrepancy against URLs.

I’m not sure if that answers your question, but in theory it could be as simple as taking and validating those headers from the initial request on the remote server, and then forwarding the request if it satisfies the conditions.

1 Like