I am trying to build a small app using Flutter to read and write from Solid pods. But I am stuck with the login process. I can read the public information from a pod using a simple http get. But I am not able to login to a pod using post. I am fairly new to the solid platform, so I may be missing some obvious things here.
If anyone can point me in a direction where I can find useful information (or even a simple guide/tutorial) to get around this, that would be much appreciated
@jeffz Thank you for your reply and all the information. I am planning to try out your solid-node-client. Hopefully, I will be able to get the login sorted out.
I haven’t checked them myself, but it looks like there are community implementations of Solid’s authentication protocol (Solid-OIDC) in Rust, in Swift, in Kotlin (using Spring) and in Perl, in case they’re helpful.
@kayon@Anushka I would be very interested to know how you get on with your various research areas. Thank you in advance for anything you post back and share.
@kayon I haven’t come across anything like that yet. Still investigating the possibilities. Will make sure to share anything I find useful to tackle this.
Hi @Anushka ! As @jeffz mentioned, authentication in Solid is based on an extension to the OpenID Connect protocol, named Solid-OIDC. OpenID Connect itself is based on OAuth 2.0, which defines a general flow for authentication. Typically, think about how “Log in with Google” works:
You start from your app, and click login
You get redirected to the Google login screen, and provide your login/password/2FA/biometrics to Google (not to your application)
If Google recognizes you, it redirects you back to your app
You are now logged in your app.
Now, replace “Google” by “Solid Identity Provider” in this example, and you have a general idea of how authentication works in Solid. That’s the flow implemented by @inrupt/solid-client-authn-* client libraries, as well as all the libraries @Vincent listed. I’m not aware of existing Flutter clients, but I expect there are Flutter clients for OAuth/OIDC, which would only need little tweaks to be compliant with Solid-OIDC.
Thanks a lot @zwifi. There is actually a Dart open id client package that I am trying to use to implement the Solid-OIDC flow. So, if I understand correctly from the Solid OIDC Primer the client needs to be pre-registered in the OPs system and should have a client ID of its own in order to get the authorization part done. Is this client registration is another POD registration in the same OP or is there a different registration for clients?
As a matter of fact, a somewhat similar question was asked this morning on Gitter, so I’ll paste here part of my answer there :).
static client registration is vanilla OIDC (even OAuth 2.0) concept, where the app developer uses an out-of-band mechanism to get a client id/secret pair from a given Identity Provier, that the app can later re-use to be identified by the same Identity Provider. In this case, the identifiers is server-managed, and the developer manually provides client information when registering.
On the other hand, Solid Client identifiers (the spec is walking away from calling them WebID for technical reasons, but they’re very much similar to a WebID for apps) is a Solid-OIDC-specific mechanism, where the client is in control of its identifier, which dereferences to a document where client information may be found by the identity provider. Details are provided in the draft spec: Solid-OIDC
In an open ecosystem such as Solid, where a given user is free to use the Identity Provider of their choice, regular static registration doesn’t scale, which is why the alternative mechanism has been proposed.
So to specify in the context of your question: the client (i.e. the app) registration is different from the Pod provisioning. Your client can either be statically registered, or dynamically registered (which is the default behaviour). In any case, the Identity Provider doesn’t have to be related to the Pod provider in any way, that’s the beauty of open systems.
Thanks a lot @zwifi. I think I got it. So according to Solid-OIDC a client ID can be a WebID that points to a JSON-LD document. Or else the client needs to do either static or dynamic registration and the dynamic registration is the default behaviour. I need to have another deep look into this. Thanks again!
So I finally managed to get the authentication and authorisation part working with Dart openid_cient library. Now I am getting a Bearer access token from the Identity Provider. But as I understand I should get a DPoP token to be able to edit data in my POD using the client app? For that, the client needs to implement a DPoP key pair using elliptic curves according to Solid OIDC Primer. Does my understanding of this correct? Do clients always need to use elliptic curves to generate key pairs?
I’m not sure about elliptic curves specifically, but my understanding agrees with what you are saying: You need to create a DPoP token to be able to upload/download files and/or RDF’s from a Solid resource server. I have not at this point created public/private key pairs on a mobile client. I’ve only created them for a backend server and that public/private key pair is going to be static. For iOS mobile, this is what I’ve gleaned so far for creating public/private key pairs. But, note I haven’t tried that yet. And for Flutter, the specifics will of course vary
Indeed, binding the access token to a DPoP key is highly recommanded security best practice. Technically, Elliptic Curves aren’t necessarily required, and each Solid Identity Provider should list the algorithms it supports in its configuration document (available at .well-known/openid-configuration, for instance https://broker.pod.inrupt.com/.well-known/openid-configuration. Elliptic Curve signatures are widely supported, so they seem to be a good default.
This said, you should be able to make authenticated requests to your Pod with a regular Bearer access token. Making it a DPoP-bound access token provides a protection against token extraction, which is really important in an open ecosystem such as Solid.
Thanks for your help @crspybits and @zwifi. I finally managed to complete the authentication part. I am now looking at creating, editing data in a pod using the app and ACLs. Excited to learn more. Also, I will soon share my experience in getting the authentication part done using Flutter
I got the basic pub.dev openid_client running. I registered it as a desktop application with google and got my clientid and secret and run it on the command line.
I’m now trying to figure out how to register my test command line app with inrupt.com’s pod server and/or my local Community Solid Server. I assume either can serve as an openid IdP and not just as a resource. How do I register an app with a Solid IdP to get a client id and secret? Its not clear to me from Solid-OIDC Is there another way to set it up? thanks
You can use the generate-oidc-token tool to generate the credentials and use them in your command line app. Here are the docs that explain how it works.
A long overdue, but here’s the Solid Authentication package for flutter apps Solid Auth. It implements Solid-OIDC flow which can be used to authenticate a client application to a Solid POD. Currently works with both Android and Web platforms.
