It looks like I'm not going to be able to get an access token on iOS. However, it does look like I can get an id token in the AuthorizationResponse when I use responseTypes: [.code, .idToken].
So, to make request of sync server, I'm going to use the id token. As with Apple Sign In, I'm not going to be able to consistently validate the expiry of the id token. However, unlike Apple Sign In, I can generate a refresh token on the server which can be used to re-make access tokens.
So, the overall architecture of the sync server sign-in/Pod components will be:
iOSSolid
Credentials plugin for iOSSignIn. It will generate an id token. It will also send CodeParameters (see SolidAuthSwift).
CredentialsSolid
A Kitura plugin. It will use SolidAuthSwift to (partly) validate an id token. It will also take other parameters (including an authorization code) to pass along to the sync server. It will use an endpoint in CodeParameters to fetch public keys from the Solid Pod issuer with which to validate the id token. The users webid can be extracted from the id token and passed along to the sync server as the users id. Note that the plan, unfortunately, is to use just weak validation of the id token. Since we seem unable to (a) get an access token and (b) refresh that access token on the iOS client (i.e., without using a key pair on the iOS client-- which seems inherently insecure), I'm just going to use the id token that I can get without use of the key pair. But that id token will expire. I'm going to rely on further layers in the server to get the access token and refresh it, and if that fails to pass it back to the iOS client it to sign the user out.
ServerSolidAccount
Provides sync server Account and CloudStorage conformance. CloudStorage conformance will enable access to files in the Pod.
I'm adding use of Solid Pod's to Neebla. This is the draft sign in library: https://github.com/crspybits/SolidAuthSwift
It looks like I'm not going to be able to get an access token on iOS. However, it does look like I can get an id token in the
AuthorizationResponsewhen I useresponseTypes: [.code, .idToken].So, to make request of sync server, I'm going to use the id token. As with Apple Sign In, I'm not going to be able to consistently validate the expiry of the id token. However, unlike Apple Sign In, I can generate a refresh token on the server which can be used to re-make access tokens.
So, the overall architecture of the sync server sign-in/Pod components will be:
iOSSolid
Credentials plugin for iOSSignIn. It will generate an id token. It will also send
CodeParameters(see SolidAuthSwift).CredentialsSolid
A Kitura plugin. It will use SolidAuthSwift to (partly) validate an id token. It will also take other parameters (including an authorization code) to pass along to the sync server. It will use an endpoint in
CodeParametersto fetch public keys from the Solid Pod issuer with which to validate the id token. The users webid can be extracted from the id token and passed along to the sync server as the users id. Note that the plan, unfortunately, is to use just weak validation of the id token. Since we seem unable to (a) get an access token and (b) refresh that access token on the iOS client (i.e., without using a key pair on the iOS client-- which seems inherently insecure), I'm just going to use the id token that I can get without use of the key pair. But that id token will expire. I'm going to rely on further layers in the server to get the access token and refresh it, and if that fails to pass it back to the iOS client it to sign the user out.ServerSolidAccount
Provides sync server
AccountandCloudStorageconformance.CloudStorageconformance will enable access to files in the Pod.