Authentication problems with only

Hello all,

I’m developing several apps on top of Solid, and testing them regularly against various pod providers. I’ve been having problems specifically with (at least recently - I think it used to work months ago, but not sure) with the authentication flow, while it works with all other providers I could test (podspaces, solidweb, teamId,, …)

Here’s what happens :
(my understanding of the auth flow is very basic - please bear with my approximate description of the problem)

  • I have a basic browser app that requires the user to log in, and then fetch some resources. Nothing fancy.
  • I’m using the inrupt solid client lib and inrupt react hooks and contexts to implement this
  • on first login, while the session object looks ok and I appear to have an authenticated fetch function, all HTTP requests end up with a 403
  • only after refreshing the page (and triggering the restoreSession behaviour of the inrupt lib), the requests succeed as expected
  • upon inspection of the network logs, it appears that the failing requests use a Bearer authentication token, while the succeeding requests have a DPop token type
  • with all other providers, the HTTP log looks the same (both during the auth handshake, and when requesting resources), but in that case the Bearer token is accepted.

Does that ring a bell to anyone ?

Two more remarks :

  • i’m mentioning the Bearer token thing, because it’s the only difference I notice. Maybe it’s totally irrelevant.
  • among the other succesfully tested providers, there is inrupt. net , which is also a NSS instance (albeit a 5.7.10, while solidcommunity is 5.7.11 at the time of writing)


@bourgeoa and @gaz009 ^^.


I think I know the answer to this one. One of the supporting libraries which the NodeSolidServer uses is nodesolidserver/oidc-op. An open issue that hasn’t been addressed is the usage of the DPoP access token returning a token type of “bearer” as you can see here. It’s an open issue I haven’t gotten around to merging/fixing yet, as most users of NSS to my knowledge are still using the Bearer token type. It also doesn’t make use of the “webid” claim yet.

does that explain the fact that it works ok with, running on almost the same version of the NSS ?

Sorry, I thought your original post said “”. You’re right, is running 5.7.10, but there were no changes to any of the OIDC components of NSS from 5.7.10 to 5.7.11. Only unit tests were changed. It also appears the OIDC documents are the same for both of them, so you should be receiving the same response.

Two questions:

  1. You are testing against and not, correct?
  2. You are receiving a Bearer ID token, redeeming it for a Bearer Access token, and using this access token is sending you a 403?

If you could open an issue at the repository with more information, I respond more frequently there.

sorry it took me so long to get back to you.
I have more information in the mean time :

  • the problem arises with too (it’s just that pods have the root public by default, so the auth problem did not show at first glance). So it is indeed a NSS behaviour.
  • the cause of the problem was because I set the login options to use ‘Bearer’ instead of DPoP. Settting it back to DPoP solves it.

So I suppose the NSS simply does not support Bearer as a token type ?
In which case sorry for my mistake; i won’t file an issue in the repo then.


1 Like