This has some resemblance to POD Authentification from another server (not solid) but isn’t quite the same, so I’m starting a new topic.
I’m trying to work out a general purpose mechanism (e.g., across Solid Pod providers) regarding what info needs to get sent to my custom server from my client mobile iOS app. The architecture of the system looks like this:
-
Client mobile iOS app
-
Custom server, used by that client iOS app.
-
Some collection of Solid issuers / Solid resource servers.
3.1. The client iOS app will connect to these servers for authentication. When a user signs into the Client mobile iOS app, they give their Solid issuer, and then of course go through the username/password screen with the redirect.
3.2. The custom server will use these servers for (a) validating id or access tokens, (b) refreshing access tokens, and (c) making resource requests to upload and download files. (In my case these are binary files such as images, text files, and movie files, not RDF’s).
One aspect of this architecture that may be slightly different than others is that the mobile client uses the Solid id token in order to authenticate with the custom server (this could be an access token too, I’m just planning on using an id token). This is a convenience for the mobile client and the custom server. My system doesn’t have its own sign in system; it uses the tokens of other sign in systems for its own initial authentication. (The custom server does have its own accounts-- but the initial authentication gating access into the custom server are 3rd party tokens).
To accommodate the current variations in Solid issuers, I think what I need to do is:
On my mobile client after the Solid /authorization endpoint request, in all cases I’ll make a /token request which will give me a refresh token and ensure I have an id token. It seems that across current Solid issuers this can be done purely by authenticating with a client secret, so I will not have to have a public/private key pair on the mobile client.
After this, I’ll send the following to my custom server:
A. The id token: Need as mentioned above for initial authentication with my custom server.
B. The refresh token. Needed on the custom server for it to have updated access tokens.
C. The users storage IRI. Needed to make resource requests.
D. The client secret. Needed by some Solid issuers for making a /token request – i.e., to update the refresh token.
E. A few other pieces of info needed to make /token requests or to verify id tokens (e.g., the URL for the endpoint to get the public keys to decode the id token).
Does the sound right? The only thing that seems a little odd to me is the step of sending the client secret to my custom server. But then again, I think in terms of Solid both my iOS client and custom server are the “client”.
This question is also here: What to send to a custom server? · Issue #6 · crspybits/SolidAuthSwift · GitHub