I’m developing several apps on top of Solid, and testing them regularly against various pod providers. I’ve been having problems specifically with solidcommunity.net (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, inrupt.net, …)
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)
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.
Sorry, I thought your original post said “inrupt.com”. You’re right, inrupt.net 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.
sorry it took me so long to get back to you.
I have more information in the mean time :
the problem arises with inrupt.net too (it’s just that inrupt.net 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.
It should be supporting the Bearer token type, but the OIDC libraries written for NSS are rather old and unmaintained. I had plans to update them a while back but I am currently busy with a different project.
One other potential project is having an open-source Solid-OIDC compliant authorization server. Right now, the Solid-compliant server implementations - that I am aware of - provide AS (Authorization Server)/RS (Resource server) or just RS, but there is no standalone AS implementation.