articleBody
| -
Got it. So, the easy (though not exactly optimal) short-term
answer is to have the application log in using those credentials,
via the /login endpoint, and then just use the obtained cookie with
its requests.
For an example of how to do that in code, take a look at the
performLogin function in
solid-cli (that function uses username + password credentials,
but the same logic would apply with a WebID TLS certificate as
credential).
The proper way to do this would be… well, it depends.
There’s two basic options that come with trade-offs:
1 - User Token approach
A long-lived WebID-OIDC access token, which is a mechanism where
a user delegates access to the app. This is a common pattern with
app delegation; for example, Facebook calls this User Access Token. The benefit of this
approach is that the app itself does not store the user
credentials. The downside is that a human has to be involved (at
least during app setup) to enter in their credentials. This is kind
of like whole-disk-encryption – it’s great, and secure, but
it’s annoying that a sysadmin has to be present every time the
server reboots (to enter in the encryption password). This option
can be done right now, with no alterations to Solid Server.
(although we can probably add a nicer UI for a developer to
register their own app).
2 - App Token approach
Giving an app its own credentials, its own identity. For
example, Google does this with their Service Accounts (see their guide on Server to Server
Applications), and Facebook does this with App Access Tokens. The benefit of this
approach is - again, the app does not store user credentials, and
it’s possible to have fine-grained permissions just for the app,
separate from the user. But that’s also the downside, since you
have to modify your ACLs to specifically give access to the app.
(Notice that both Google and Facebook specifically limit what an
app access token can do, it has many fewer privileges than a user
token.)
|