Are there actually implementations which implemented the current solid OIDC specification ?
It looks like both CSS and NSS ( Inrupt) are not returning an WWW-Authenticate header with an as_uri parameter while the Solid OIDC spec states it is a MUST.
At least CSS has implemented it. I don’t know how it should work, but you can look through the code and issues by searching on their repo, eg Search · WWW-authenticate · GitHub
Note that NSS isn’t an Inrupt product, it is a legacy community project that preceded CSS.
The Inrupt product, ESS (for Enterprise Solid Server) implements the latest Solid-OIDC, and returns an UMA-compliant WWW-Authenticate header with an as_uri parameter on unauthenticated requests. If you have a Pod on Podspaces, you can use any REST client to check this by issuing a GET request to your Pod root.
Thx for the answers.
I was tracing a podbrowser session to my podspaces pod and was expecting to see the 401 on the requests to my pod.
But with the first requests the authorization ( access token) and dpop headers where already sent.
I should probably rephrase the question:
Based on what information does podbrowser decide to already sent the access token ? Usually this is based on the audience claim ( base url) , but in this case the audience is “solid”
Podbrowser is using @inrupt/solid-client-authn-browser, so what is relevant to your question is the behaviour of the library. For the time being, it does not implement reactive authorization, where an unauthenticated request is sent in order to discover authentication mechanisms based on the WWW-Authenticate header of the 401 response. Instead, it implements the legacy behaviour that was in place before the current version of then Solid-OIDC specification, namely it relies on the Resource Server accepting the Access Token issued by the OpenId Provider. In other words, it implements preemptive authorization, by sending a token along the request without the initial round-trip. This legacy behavior is currently supported by all major Solid Server implementations, and it isn’t mutually exclusive with the mechanism described in Solid-OIDC, so there is no plan I’m aware of to remove this mechanism in the short term. We will be working in the future on implementing reactive authentication in @inrupt/solid-client-authn-*.
Does that answer your question?
1 Like
Yes it does, thank you