Not logged in : Login

About:     Goto   Sponge   NotDistinct   Permalink

An Entity of Type : schema:DiscussionForumPosting, within Data Space : associated with source document(s)

  • 0
described by
container of
  • #2
  • #4
  • 2018-11-09T22:09:15Z
  • 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.)
  • UserComments:0
  • UserLikes:0
  • POD Authentification from another server (not solid)
is interactionStatistic of
is topic of
is container of of
is object of
is subject of
Faceted Search & Find service v1.17_git38 as of Aug 05 2019

Alternative Linked Data Documents: ODE     Content Formats:       RDF       ODATA       Microdata      About   
This material is Open Knowledge   W3C Semantic Web Technology [RDF Data] Valid XHTML + RDFa
OpenLink Virtuoso version 08.01.3307 as of May 21 2018, on Linux (x86_64-redhat-linux-gnu-ANALYTICS), Single-Server Edition (7 GB total memory)
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2021 OpenLink Software