I’ve just started building my first Solid app. It’s a basic pod browser that allows you to navigate your pod and add/delete resources. You can find it here - any feedback most welcome!
It currently only works with pods hosted at Inrupt’s Pod Spaces (no NSS support), and does not yet support changing permissions on resources. But I thought I’d share it now anyway in order to get early feedback. Please do let me know if you have any comments / questions or suggestions for improvements.
The main reason is that Inrupt’s Enterprise Solid Server uses Access Control Policies (ACP) for permission management, but NSS uses Web Access Control (WAC). There seem to be some other differences as well, but that’s the main one.
Welll, I can say that the sign-in screen looks gorgeous, but unfortunately I cannot go beyond that:
Also: ACP and WAC should only affect the way you set permissions for particular resources, so it doesn’t seem like that should affect the ability to use an app beyond that? We’re happy to help diagnosing further issues here - after all, interoperability is a key tenet of Solid
One thing you can already try is to see if you can use the app with https://broker.pod-compat.inrupt.com/ as well, which is the same server software, but using WAC. If that works, then WAC/ACP cannot be the issue.
Another question, out of interest: is the source code somewhere we can look at, perchance? And if not, would you care to at least share what tools you are using?
Ah, that’s annoying! I’m doing dynamic client registration and I noticed in development that my client ID would sometimes stop being recognised after a period of time. Does anyone know why this might be? I’ve put a temporary fix in to re-register the client periodically so you should be able to sign in now, but this doesn’t seem like the right solution.
I will cetainly try testing the app with https://broker.pod-compat.inrupt.com/ . Another reason it’s not currently working with NSS is that I validate the tokens returned by the server according to the Solid OIDC spec and some of the claims seem to differ from what I’m expecting. For instance, the web_id and client_id claims are missing from the access token, and the aud claim contains the client id rather than the string “solid”.
The source code is not currently public, but it’s written in Elixir (using the Phoenix framework).
I believe solid-client-authn does a new dynamic registration every time someone signs in, so maybe that would be something for you to consider doing too? As far as I know proposals are underway in the authentication panel to obviate the need for dynamic registration, so hopefully a better longer-term solution will soon be available.
Anyway, it works flawlessly now and looks very good, good job!
Another difference between NSS and the Solid Spaces Server (ESS) is that ESS uses by default DPoP (Demonstration of Proof of Possession) for the Auth tokens and NSS the old PoP. That’s exactly what you mention about the missing claims.
Another reason it’s not currently working with NSS is that I validate the tokens returned by the server according to the Solid OIDC spec and some of the claims seem to differ from what I’m expecting. For instance, the web_id and client_id claims are missing from the access token, and the aud claim contains the client id rather than the string “solid”.
Note that the Access Token is meant to be opaque for the client app, it is only the resource server that should do validation on it. You should still validate the ID token though, which is meant for the client app, and will never be transmitted to the Resource Server. The webid claim should still be present though, but you should get a 401 when trying to use the token rather than validating it at the app level (even though the fact that the token structure is part of the spec means that you can technically validate it, even if it’s not really in line with the OAuth/OIDC philosophy ^^).
Another difference between NSS and the Solid Spaces Server (ESS) is that ESS uses by default DPoP (Demonstration of Proof of Possession) for the Auth tokens and NSS the old PoP. That’s exactly what you mention about the missing claims.
To be exact, both ESS and NSS (>= 5.3.0) implement support for DPoP tokens (only NSS supports the legacy PoP tokens, and ESS supports regular OAuth bearer tokens). If you are using solid-client-authn-*) and an up-to-date version of NSS (as deployed on solidcommunity.net or inrupt.net), you should be able to authenticate to both, since solid-client-authn-* defaults to DPoP, unless specifically told otherwise (in which case you would indeed have issues against NSS).
Could you capture the traffic between your browser and the Solid Identity Provider when logging in, and in particular the calls to the /token endpoint ? That’s when your app gets its set of tokens, and depending on how these calls look we should be able to check wether a DPoP or Bearer token is issued. Please be sure to obfuscate some elements in the token: if it’s a DPoP token, it cannot be replayed without the private key, so you’ll be fine, but in the case you’re asking for a Bearer token, there is no mechanism to prevent the token being exfiltrated and replayed. Note that the token will only be valid a couple of minutes anyways, so the risk isn’t THAT big, but just to be on the safe side of things
Ah ok, that makes sense! And will make my code marginally simpler
My validation expects a webid claim to be present in the ID token, but this claims seems to be missing from the ID tokens returned by both solidcommunity.net and inrupt.net. From my reading of the spec, this should be present - am I understanding that correctly?
I’m not using solid-client-authn-*, but looking at the tokens, I can confirm that both solidcommunity.net and inrupt.net are returning DPoP tokens.
You are correct that the spec you referenced requires the webid claim to be present. Unfortunately, what you are reading there is the new spec, which is still in draft state :). The current spec that applies is https://github.com/solid/webid-oidc-spec (to the best of my knowledge), which allows the subject claim (sub) to contain the WebID in the absence of a webid claim, which is what NSS does:
As per the current spec, this is also valid, and yields the same result as if the same WebID was in a dedicated webid claim.
And yeah right, you mentioned that your app was in Elixir, so actually I should have guessed that you weren’t using a JavaScript library in it ^^. I’m happy to help with any additional auth-related questions if you still have issues.
Ah ok, it’s not always super obvious to me which specs are being applied where! I’ve updated the code to fallback to looking for a web ID in the sub claim if a webid claim is not present and that all seems to work. So it is now possible to login with pods hosted on NSS Thank you for your help!
One other small validation issue I ran into with NSS was that I was expecting the token_type header in the token response to be “DPoP”. But NSS seems to return “Bearer” even when the access token is in fact a DPoP token. I’ve just stopped checking this header for now, but is it intended that this value be ignored?
Thank you for your help!
.