Hi, I’m trying to make a mobile SOLID app in Flutter. (cross-platform Android, iOS)
Logging in with solid-node-client through a custom api is easy enough.
The problem is that the app is not supposed to have access to all my data.
With the current implementations, I’m restricted to either give full access by logging in or making the data public.
Because mobile apps don’t send an http-origin header.
Does anyone have an idea how I could give restricted access to a mobile app.
I found the thread about OCAP , but that still seems to be under discussion?
If I create a webID for the app, it would need to authenticate in it’s code, so that’s a security risk in itself.
Are you getting 403 errors? Those are the only ones related to origin. AFAIK, origin is irrelevant for command-line apps with the server assuming that you are coming from your own machine. If you are coming from a localhost, that needs to be declared as a trustedOrigin. The way ACL works, logging in should give you access to everything you as a user have access to and nothing else. If other people are using your app, your app should prompt them for credentials and then login as them, not as the app. Not sure I’ve understood your problem though …
Hi @jeffz, no it’s not really a problem with authorization.
So no errors.
If I log in with my webID I have access to all my data.
But there lies the problem.
The app should not have access to all my data.
I could use a trustedOrigin to give access to certain parts of my data with ACL/ACP
The problem with mobile apps is that trustedOrigin is only based on the HTTP-origin header, but mobile apps don’t send this header.
I could create a webID for the app, but then I’d have to hard-code the credentials, which can’t be the idea.
To summarize:
A mobile app only needs access to a certain part of my pod, but does not send out an http-origin header, so I can’t use trustedOrigin.
Do you think there’s a way to accomplish this? Or is SOLID as it is today not for specific mobile development?
I’m afraid I don’t see the problem. If a user has credentials to login, why does your app care what they do with those credentials? Why should the app be able to restrict what a user does?
The problem, I think, is that @johan does not want that all his data can be accessed by an app, ex if I build an app for movie recommandation, I don’t want the app can access my health data,
When we allow an app, that app can do everything on the POD.
With the share panel, you should be able to manage access more granuraly, on resource level
I’m sorry that, does not make sense to me. Why would I want to allow myself to see my whole pod with one app see only part with another? What is the point of restricting yourself from seeing your pod?
No, it’s the app that should have restricted access.
As @Smag0 said, an app for movie recommendation should not see my health data.
The user only provides his webID and the mobile app only has been granted access to the part of my pod with the data specific for that app.
If I log in, the mobile app could have access to all my data.
The problem is that ACL/ACP for applications only works with http-origin headers, but mobile apps don’t send these. So I can’t whitelist a mobile app.
A webapp on the other hand does send http-origin headers.
The insurance company can not log in as you. If your private data is marked as only accessible by you, the insurance company can’t see it, no matter what app they use. If you have a personal app that only logs in as you, what is the problem if that app can see the whole pod?
Okay, now I see your use case. The insurance company writes an app which you install on your mobile and you login with it. The problem only occurs if the app sends something to the insurance company, which it absolutely should not do. Hell, it could just record your login credentials and send those to the insurance company. A Solid app on your mobile that sends data to any third party is a malicious app. If the insurance company needs to see the data, they need to login as themselves and go to your pod and see the parts of the data you have given them access to.
Under no circumstances should the insurance company or any third party be able to see what you access when you are logged in as you, even your public data.
I see your point.
A solid app should just be a view.
Due to paranoia, we’re used to thinking that if an app has full access, the “company” has access.
And idd, they could record the login, …
The problem is, it can’t be enforced, as such.
If someone steals the password to, let’s say a webshop, they only have access to the webshop.
But if they steal your webID credentials, they have the complete pod.
srry thinking out loud
This is turning out to be a point pro OCAP, I think.
See the section on client identifiers in the latest draft of the authentication protocol. The net result is a token presented to the resource server that claims:
I have control of this WebID
I am using this client, identified by the client application WebID
Authorization statements on the Solid server side will be able to make rules that can extend to check against the client in use. Keep in mind that there are still some shortcomings to this when controlling what applications other people are using to access your data - detailed here - but still quite effective for many important use cases, including the one you presented.
Thanks much @justin. Here’s my guess at how the spec you pointed to would handle the specific use case @johan brought up. Please correct me if I’ve misunderstood.
All apps that want authenticated access, including command line apps. will need to post a public webId identifying the app. This webId can be used in defining trustedApps for specific parts of a pod, thus limiting what the app can access. This mechanism does not depend on origin checking for apps so could be used to limit access of command-line apps that have no origin.
Yup.
Of course this will always boil down to trust somewhere.
Once you can identify an app using a WebId then you need a way to trust that the app is safe.
I can think of many ways this can be done in future.
Thanks @emmettownsend and @justin. While I have your attention, let me display my lack of OIDC knowledge and ask some dumb questions.
What about the underlying fetchers for the app (e.g. solid-client-authn-node or solid-node-client) - do they have clientIdentifiers or only the app that uses them?
What about one-off command line scripts that use those fetchers, do they need clientIdentifiers?
And is this how the OIDC bits are used?
The app creator gets a clientIdentifier from an issuer and uses it to create a public WebId document for the app (this is a one time thing).
The app should provide a login mechanism which allows the user to login and then the app gets a bearer token from the login which will then be used by the fetcher to send along with the clientIdentifier in all authenticated fetches.
Hmm, I’ve left out clientSecret and accessToken, where do they fit in?
What about an app that is meant to be single-user and run from the user’s device – can they store an accessToken and use it repeatedly?
I’ve read a million OIDC explanations and still am confused.
What about one-off command line scripts that use those fetchers, do they need clientIdentifiers?
They don’t need them, but they could have them, if you wanted to make authorization rules related to them, or if you needed to allow them explicitly (vs. other utilities or apps)
And is this how the OIDC bits are used?
The app creator gets a clientIdentifier from an issuer and uses it to create a public WebId document for the app (this is a one time thing).
The app should provide a login mechanism which allows the user to login and then the app gets a bearer token from the login which will then be used by the fetcher to send along with the clientIdentifier in all authenticated fetches.
If by login mechanism you mean a Solid-OIDC compliant authentication scheme with an IdP in the mix then yes - this is the exact flow. Note that the client identifier is included as a claim in the DPOP-bound access token.
What about an app that is meant to be single-user and run from the user’s device – can they store an accessToken and use it repeatedly?
