| articleBody
| -
Hi @mguiral, that’s
an excellent question. So, part of the answer is going to be - what
do you mean by an app performing a login action? Will the app have
its own WebID, and so be present in various access control lists?
Or would you like the app to login on behalf of a particular
user?
-
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.)
-
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.)
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
