How to authenticate an App with its own identity (e.g. WebID)?

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.

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

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

3 Likes

I know we’ve definitely done what you describe at Inrupt, but I don’t think we’ve anything published about it, nor what compatibility is like. I’ll ask around.

1 Like

I love this write-up! Thank you @renyuneyun for sharing your research in such detail!

We’re going to need this for creating an index service on top of data with access limited to a certain group of people.

Also, potentially, to create an email notification service that would send email when an observed (private) document changes.

So, I’m excited to see this thread here :heart: and looking forward to more

This app could be of interest. GitHub - o-development/clone-to-solid-pod: Github action to clone the contents of a github repo to a Solid Pod
It does copy from GitHub to a solid pod using solid-node-client. Tested on NSS and CSS.

This is also related to a SolidLab challenge that is still open. See also the comment by laurencedeb.

By the way, with CSS’s Client Credential the problem for command line access was solved for me. My server-side tools just need one CSS to define its own WebID and Solid-OIDC. To this CSS the service can authenticate and with that authenticated WebID it can browse the rest of the Solid universe. It would be nicer to have a slimmed down version of CSS only containing the Solid-OIDC part, but it is what it is.

Check GitHub - SolidLabResearch/Bashlib: A Node.JS and CLI interface for Solid for a client. We use this all in an orchestration service GitHub - eyereasoner/Koreografeye: A web choreography service using eye . It watches LDN inboxes and executes scripts based on routing with Notation3 rules.