What to send to a custom server? #6
Description
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 for authentication. When a user signs into the Client mobile iOS app, they give their Solid issuer.
3.2. The custom server will use them 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 a 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. My system doesn't have its own sign in system; it uses the tokens of other sign 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 /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.
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).