inrupt
Ability to retrieve Authorization and Dpop headers
Search terms you've used
I posed a question to https://gitter.im/solid/app-development on 18-Mar-2021.
Impacted environment
In which environment would the proposed feature apply ?
- [ X] The browser
- [ ] Node.js
- [ ] Other (please specify): ...
- [ ] I'm not sure.
Feature suggestion
A way to use @inrupt/solid-client-authn-browser to retrieve the Authorization: and Dpop: headers without making the fetch. I want to put those headers into another e.g. PUT call generated by a 3rd party library.
Expected functionality/enhancement
I could call a JS function/method from my browser code to retrieve the headers which I could then add during events generated but a 3rd party library like Dropzone.
Actual functionality/enhancement
The capability doesn't currently exist.
Use Cases
During a Dropzone initialization event of a file upload the ability exists to modify the request headers. If I had the ability to retrieve the Authorization: and Dpop: headers I could add them to the request headers during this event creating a solid authenticated request.
The ability to etrieve the Authorization: and Dpop: headers without making a fetch doesn't currently exist in @inrupt/solid-client-authn-browser
The Authorization and the DPoP headers are both generated from sensitive data, respectively the access token and the DPoP key. Both these pieces of data are crucial, because they are what enable authenticated requests to the Solid Server. For this reason, we made the decision in the design of solid-client-authn-* that they are only ever stored in the fetch function closure. This intends at preventing them from being potentially extracted by any malicious script running on the same page as your app.
Unfortunately, that means that what you are asking for isn't directly possible with our security model. However, looking at dropzone's documentation, and in particular at https://www.dropzonejs.com/#event-sending, I guess an option would be that we somehow expose a way of setting the headers on a provided xhr object. Before committing to anything, let me took it up with other engineers of the team to make sure there's a secure way to do so ^^.
We definitely support this issue !
We, at Startinblox, are using our own sib-core client library to execute every requests to our PODs and resources servers.
When using solid-auth-client (which is deprecated now) we used to call the getUserIdToken method and use its result to be passed as the Authorization: Bearer header, as you can see here
We need a way to fetch that token in a way we can securily pass it to other libraries. I guess if we check what solid-client-js is doing with the fetch closure we could reproduce the behaviour, but if there is a shortcut to that, that would be great.
Otherwise we are blocked in our migration away from solid-auth-client and DPOP support implementation :-(
@balessan Ah, looking at your code, it seems to me that instead of storing a token on a headers property, you could have your constructor take a fetch function instead, and then in fetchData you call that rather than the global fetch. If the user then passes in that function from solid-client-authn-browser, it will add the necessary headers to authenticate the request. Would that work for you?
@Vinnl at least it needs to be investigated. We'll check that, thanks for the feedback.
We have an additional use-case where we previously forwarded the Authorization headers to allow us to authenticate a user from Prosody (XMPP server) on DjangoLDP (our Solid/LDP server).
To do that we explicitely forwarded on the initialization of the XMPP client side component, which then triggered the user authentication with the proper paramaters. The issue here is that Prosody is server-side, implemented in lua. So no way for us to exploit the same fetch() method to achieve anything.
How could we do that without the need to implement the full solid-oidc spec compliance on Prosody side ?
The only workarounds we thought of are really dirty, and possible security issues. We are kind of stuck by delay and budgetting issues here.
A possible alternative is to open(export) the solid-client-authn-browser module API. By doing this we can extend the classes to implement the specific needs of each project. For example, exposing the ClientAuthentication class and its dependencies (dependencies.ts) we can customize almost everything. Also, it would be nice if some class members were protected, rather than private, especially in the ClientAuthentication class.
The approach we are looking at right now is to split the API in two, with a low-level API and a high-level one. The latter would be similar to the current API, and it isn't really meant to be extended, as there are some assumptions in the internal code which would be harder to manage if it became extension points. However, the former being a low-level library, it should not handle the tokens or keys for the user, this responsibility is delegated to the calling library. The high-level API would wrap this up so that "regular" use cases are still covered with no additional work, but a broader diversity of use cases would be covered because this low-level library would make much fewer assumptions. It would also give fewer guarantees, and it is meant for developers with OIDC experience, but that's usually okay for people having specific use cases in mind.