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
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