User token and security - why SOLID server does not include the origin of the requester in token?

I was wondering the following : when I connect to a solid app, I then get a bearer token, stored in the Authorization header. Once I get this token, I can potentially use it anywhere, for instance on a backend server. I can make http calls to my POD using this token and the call will then be sent with origin = null and the call will be allowed by the SOLID server.

I am not a security expert as such, but : why the SOLID server is not creating the token including the origin of the caller in it ? and then forbid any calls using this token if the call is not coming from the app who actually requested the token ?

Am I missing something ?

Sorry, I don’t know the answer to that but if nobody answers here you might want to ask at or The latter is for the app authorization panel, which is at I don’t know if they welcome questions from the public but they have meeting minutes and an issue list there. I searched on ‘token’ in the minutes and saw that they have a lot of plans. If you find an answer please post it back here too :slight_smile:

Thank you, I will write on the chat then

Are you sure about that? I think(!) the token is generated for a specific client id

This would not change much. A backend server or curl can send any value as Origin header. It is important to understand that the Origin check is only protecting the user from malicious app requests in a browser (e.g. XSS). It does not protect the pod itself.

Thank you for your feedback.

My use case is the following :

  • I connect to my pod in a browser
  • I retrieve the bearer token from the authorization header
  • I reuse this token in my code, from my server, and can successfully connect to my pod and access private data

but your next point make sense : if origin is spoofable from code, then yes , adding origin to the token will not help.

Thank you, I get it now that origin check is only for avoid cross site scripting attacks !

ok, but this is a problem then. A XSS attack could just steal the session cookie instead of using it directly within the browser, upload it to a server and use it there to gain access to the Pod :thinking:

But then is there a way to secure this ??

yeah I guess you are right on second thought. This is usually limited by token time-to-life. But I am no security expert. Hope some expert has or will review the WebID-OpenID spec and implementions carefully. Inrupt hired Bruce Schneier, I wonder what he is working on.

Thinking about it, I think it is the same thing for any security based on signed JWT token isn’t it ? The thing is that I can easily get access on my own token from my browser, but it is probably very hard / impossible for a hacker ?

1 Like

@walter.almeida that is right. I think the assumption is that an attacker would need physical access to the machine or maybe due to a Browser vulnerability. Otherwise, the Browser isolates the Local Storage per domain/origin.
But I think your concerns arise if the Solid App is contained in an HTML page as it is the case for Dokieli. Let’s say I create a Dokieli document evil.html and you copy it to you Pod. Once you access the evil.html from your Pod, I should be able to read the Local Storage (by some js loaded in the HTML head section) since the page’s origin is now the same.

I did not test it, but I think we should check it.

1 Like

yes to be tested, this is not specific to SOLID apps though, it is a common case. Authoring HTML content as part of an app (especially including js script) is dangerous. I guess this is why for instance this rich text editor I am using to write this text is not allowing me to work on a “source code” version of my post, or use any html tags, but rather specific anchors that are then taken care of server side …

initialy I was more wondering about token security in general, for my own education, wondering why they could not be secured a step further, to make the use of stolen token much more difficult.

Then I guess it is all about combining security measure like lifetime of token, signing it, securing against script injection, avoiding any obvious back door etc. But also application side technics like multi-factor authentications, sending emails to owner when suspicious activity etc…

We are also depending on the seriousness and safety of all applications we are using …

Hi @walter.almeida, I’ve been working on getting an answer for you since you asked; sorry it took so long, and thanks for bringing this up. Since obviously security is a sensitive issue I had to verify with Inrupt’s VP of Trust and Digital Ethics, and then run that by the Solid editors, to make sure the provided info was correct - and obviously they’re all busy people.

Anyway, there is now an answer in the FAQs:

My personal interpretation (but: that might be wrong, refer to the FAQ for an authoritative answer) is that, indeed, this is a known risk, which is why the Origin-based app-trusting is still labelled as experimental, and people are working on a secure replacement.


As far as I understand, it does, as the audience of the id_token. More precisely, the user has agreed to bind this token (and all further bearer PoP tokens) to this origin.

As to why the solid server does not check it, I don’t know. I think that the “RS” role of the server does not care because it does not know that the origin is used by the Web Access Control layer.

Oh thank you @Vincent for having worked on this and for this information, I really appreciate !