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

**URL:** https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946
**Category:** Solid App Development FAQs
**Created:** [December 12, 2022, 3:55pm UTC](https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946 "2022-12-12T15:55:21Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![renyuneyun](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/renyuneyun/32/3189_2.png) [@renyuneyun](https://forum.solidproject.org/u/renyuneyun)
#### Post date: [December 12, 2022, 3:55pm UTC](https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946/1 "2022-12-12T15:55:22Z")

</div>

## Background / Objective

(I created an [earlier issue](https://github.com/SolidOS/solidos/issues/183) 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](https://github.com/solid-contrib/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](https://solidproject.org/TR/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`

> **[GitHub - solid-contrib/solid-node-client: a nodejs client for Solid](https://github.com/solid-contrib/solid-node-client)**
>
> a nodejs client for Solid

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/](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/](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.

---

<div class="post-metadata">

### Author: ![ThisIsMissEm](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/thisismissem/32/3166_2.png) [@ThisIsMissEm](https://forum.solidproject.org/u/ThisIsMissEm)
#### Post date: [December 13, 2022, 12:46pm UTC](https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946/2 "2022-12-13T12:46:59Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![mrkvon](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/mrkvon/32/3768_2.png) [@mrkvon](https://forum.solidproject.org/u/mrkvon)
#### Post date: [February 2, 2023, 12:07pm UTC](https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946/3 "2023-02-02T12:07:22Z")

</div>

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](https://forum.solidproject.org/t/index-service-for-a-social-app/5222) 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 ❤ and looking forward to more

---

<div class="post-metadata">

### Author: ![bourgeoa](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/bourgeoa/32/291_2.png) [@bourgeoa](https://forum.solidproject.org/u/bourgeoa)
#### Post date: [February 2, 2023, 9:55pm UTC](https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946/4 "2023-02-02T21:55:34Z")

</div>

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](https://github.com/o-development/clone-to-solid-pod)  
It does copy from GitHub to a solid pod using `solid-node-client`. Tested on NSS and CSS.

---

<div class="post-metadata">

### Author: ![hochstenbach](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/hochstenbach/32/2308_2.png) [@hochstenbach](https://forum.solidproject.org/u/hochstenbach)
#### Post date: [February 4, 2023, 5:58am UTC](https://forum.solidproject.org/t/how-to-authenticate-an-app-with-its-own-identity-e-g-webid/5946/5 "2023-02-04T05:58:00Z")

</div>

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

> <https://github.com/SolidLabResearch/Challenges/issues/13>
>
> \<!--
> Give the challenge a succinct, attractive title.
> 
> Example:
> Greet the us…er with their preferred name
> \--\>
> 
> \## Pitch
> \<!--
> Add in concrete terms what the problem is.
> 
> Example:
> \- Users like to be addressed by their preferred name within apps.
> - This is a name that they are known as, or use for themselves.
> \- In some cultures, this is the first name.
> - It could also be a user-chosen name or nickname.
> \- Other cultures do not have the concept of a first name, so another strategy is needed.
> \--\>
> 
> Current Solid authentication libraries are mainly targeted to browser clients where \_human agents\_ need to be identified and authenticated against a choosen OIDC provider. E.g. the prefered OIDC provider can be set in the \_WebID profile\_ of an agent. 
> The Solid OIDC identification/authentication process results after some back and forth communication in \_id\_token/access\_token\_ that typically have a lifetime ranging from a few minutes to a few days (when they aren't refreshed).
> 
> When doing server side processing of data there are other requirements:
> 
> - Server processes need to be able to run \_without any human interaction\_ (or even access to the server) ..e.g. no entering of passwords
> - Server processes could have their \_own Webid\_ not connected to a human user
> - Server processes need to proof their identity when requesting resources from remote Solid Pods
> - Many processes can run \_simultaneously\_ with the same \_Webid\_ (and thus identification/authentication requirements)
> - Each process has a plethora of choices to be implemented in any programming language
>  
> \## Desired solution
> \<!--
> Add insights in how the solution should/can look like.
> 
> Example:
> \- Encode the rules for arriving at the preferred name in a declarative way.
> - For instance, using reasoning rules.
> \- Expose the functionality via JavaScript
> - For instance, through \`getUserPreferredName\` or \`user.preferredName\`
> \--\>
> 
> In theory the current Solid-OIDC tokens are not more than a signed JWT with the WebID of the agent, a client id and the web location of the OIDC issuer. All can be in control of the a server instance (e.g. a web server that publishes its own public key on a \`/jwks\` URL with a minimal \`.well-known/openid-configuration\`).
> 
> Given an access token, adding it as \`Authorization\` and \`DPoP\` header is trivial and can be implemented easily in any programming language.
> 
> Requirements command line tool to:
> 
> \- Generate a private/public key
> \- Publish the public key as \`\<someurl\>/jwks\`
> \- Publish a minimal OpenID configuration as \`\<someurl\>/.well-known/openid-configuration\`
> \- Generate an access\_token (id\_token in the future)
> \- Given a stored access\_token generate the headers (e.g. as \`curl\` would need it)
> 
> \## Acceptance criteria
> \<!--
> Describe the criteria for a demo that needs to be built such that solution can be accepted.
> 
> Example:
> \- I want to see an example app with at the top right a user bar.
> \- This user bar shows a profile picture, and "Hi, Alex".
> - Here, "Alex" is the logged-in user's preferred name.
> \- This demo should work for people from different backgrounds.
> - people without a first name
> - people with a nickname
> - people with a chosen name
> \--\>
> 
> \- Command line tool to generate public/private keys/jwks/openid-configuration/accesstoken and headers
> \- Provide an example how the accesstoken can be used in Python, Groovy, Node , ...
> \- Provide a tool to publish jwks/openid-configuration
> \- Demonstrate that these tokens work to update a remote Solid Pod where the server WebID has given the ACL rights to update a resource
> 
> \## Pointers
> \<!--
> Add pointers to existing solutions, approaches, ideas, and so on.
> 
> Example:
> \- https://www.w3.org/International/questions/qa-personal-names
> \- https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/
> \--\>
> 
> \## Scenarios
> \<!--
> (optional) Add to which scenarios this challenge contributes.
> Pick from https://github.com/SolidLabResearch/Challenges/issues?q=label%3Ascenario
> 
> Example:
> \- https://github.com/SolidLabResearch/Challenges/issues/1234
> \--\>

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](https://github.com/SolidLabResearch/Bashlib) for a client. We use this all in an orchestration service [GitHub - eyereasoner/Koreografeye: A web choreography service using eye](https://github.com/eyereasoner/Koreografeye) . It watches LDN inboxes and executes scripts based on routing with Notation3 rules.