Background / Objective
(I created an earlier issue on SolidOS repo, which is related to half of this question, but not entirely. This post is a more comprehensive description of this question, particularly the other half.)
Normally, when using browser-based Solid Apps to access private resource, the App will need to log-in with the user’s credential, and operate on behalf of that user (thus possessing all permissions that user has). That is, the authentication confirms that this is the user doing the operation.
However, for a service-like application (or a CLI application), this does not work. The service-like application will routinely perform actions over potentially multiple users’ pods, and needs to be authenticated and authorized with its own identity. (Otherwise it needs to store users’ credentials [access token if supported, or username+password] on its own storage, which may be a problem.)
For that to work, we need the authentication to confirm that this is the application doing the operation.
Thinking and Questions
One way is to create a Pod (and thus a WebID) for the application, and authenticate in the same way as a user. Authorization is also to that WebID. That works, and I’m aware the solid-node-client library is for this purpose.
But the issue here is: it requires a Pod hosted somewhere. This seems to be an overkill, if the application developer wants to use their own domain name for the WebID – apart from the application itself, they also need to deploy a Solid service with only one Pod (whose username+password or access token is stored with the application).
If I understand correctly, what is needed is only the WebID (URI) and a service for performing Solid OIDC (OpenID Provider?). I only briefly read Solid OIDC Primer, and I’m not familiar enough with these concepts. But it seems possible to have a Web host hosting the WebID at the given URI, and specify that the WebID issuer is a OpenID Provider server to a service managed by the application developer simply for that one usage? Is there an existing library/service for that (OpenID Provider)?
In the meantime, this seems only possible for an application with its own hosting machine. Surely, for a service-like application, this is expected. But it looks like it will not work for a static-site-based Solid App (e.g. those under github.io
) – no Solid OIDC server (OpenID Provider?) will exist in that case; no secret information can be stored. Can they also authenticate themselves?
Right now, they seem to identify themselves by Origin. I didn’t manage to make “authorization by Origin” work, but guess it’s bug rather than deprecated. If considering authentication based on Origin, the situation becomes more complicated. I didn’t have a clue for adding that into, so probably it should be ignored in this thread. But if anyone already has a clear view, please do spell that out.
Known working patterns
Based on my experience (and “rumours”), there are several implementation-specific ways that may allow a service-like application to access private resources on a Pod. None of them completely solves my question above. But to be comprehensive and maybe useful for others, I’m stating them here.
solid-node-client
This method is mentioned above. Basically, it is a library that allows the CLI application to authenticate as a given account (WebID), and use that WebID to access resources. You can use it to log-in as yourself, or a dedicated account for the service-like application.
To use it, the developer needs to add this library as a trusted app to that given user (that the application will authenticate as), and use the access credentials to log-in.
Its document says you will obtain a session
object which is compatible with the session object in the underlying library (e.g. Inrupt’s solid-client-authn
).
It only supports ESS and NSS at the moment.
(I tested CSS, and it did not work. No error message is seen.)
CSS’s Client Credential
https://communitysolidserver.github.io/CommunitySolidServer/.x/usage/client-credentials/
This is a CSS-specific way to generate access tokens for applications to use. I did not see a permission control for such client credentials, so I assume the App will have all permissions.
Everything is done in code. You will obtain a fetch
object/function which is authenticated.
ESS’s Registered Application
https://docs.inrupt.com/ess/latest/services/service-application-registration/
(Note: I haven’t used this method. Information is based on description.)
ESS allows you to register applications, and give applications credentials. This is similar to the CSS’s Client Credentials (or, in general, a service’s API access tokens), but in a more well-described and
handled way.
My vague memory
Here are something I can’t find right now, but will update if found.
-
I vaguely remember previously someone told me that ESS supports Apps to authenticate themselves as some WebID. But can’t find where this is from now.
-
I also vaguely remember there is a library similar to
solid-node-client
(from a github issue discussion thread, or from a Solid World session) but gives a uniform way to authenticate for CSS and NSS.