Solid client's redirect url not used in CallbackHandler?

[jg10-mastodon-social]

It appears that the redirect url provided by a Solid client is not used and a clean origin is used instead.

css-direct-sso-auth/src/CallbackHandler.ts

Lines 174 to 176 in 90075ac

	private forgeRedirectUrl(origin: string, code: string, state: string): string {
	let origin_clean = origin.slice(-1) == '/' ? origin.slice(0, -1) : origin
	return `${origin_clean}/?code=${code}&state=${state}&iss=${this.baseUrl}`

Is the intention that arbitrary redirect URLs are not supported?

[thhck]

Thanks @jg10-mastodon-social for testing and reviewing the code ! I truly appreciate :)

Yes this is by design. In my use case arbitrary client are not needed and client should even be in an allowed client list.

Do you have a need to for arbitrary redirect URL ?

[jg10-mastodon-social]

I was testing the path by which someone would start with CSS as a Backend-as-a-Service tied to the demo app, and then seek to access their data from another app.

It seems that the two issues I submitted are the only barriers to this?

If this restriction is removed, then the user would have a clear "upgrade" path. When they start with the demo app, they don't need to know about Solid. As they get to know more, they find out that they have an auto-generated webid, and they can start using it elsewhere. That would still work with SSO, but then they could edit that too, and switch authentication method to remove dependency on Google or GitHub etc. That would be fantastic, and true to the intention of Solid.

An alternative "upgrade" path would be to offer migration of data to another pod, but this would be a bigger jump because they'd have to find one, which may not have SSO. Your solution has a cleaner incremental pathway - if it can be made to allow login from other apps.

Conversely, if accessing your data with another app is not possible (even with migration), then the demo app is only offering Solid as an option. If they don't pick that option, the data is not really the user's and they don't even have access to it from other apps.

A third "upgrade" path would be for the user's data to be stored on GitHub or Google Drive. While it would still be in GitHub and Google's custody, the user would still own the data as well as being able to migrate it to a pod in future. Arguably this would end up more consistent with the principles of Solid than a pure CSS as a Backend-as-a-Service play. It would also be consistent with @NoelDeMartin's proposal:
https://noeldemartin.com/downloads/nlnet/proxy-solid-server.pdf

I'm excited about enabling any of these three upgrade paths. The first seems like it could be functional with very little extra work!

[thhck]

I share this excitement too!

Unless I misunderstood, I'm strongly opposed to the first option. Imagine I use this module to create a Solid-compatible Tetris game at solid-tetris.com, and a non-Solid user starts using it with their Google account. I believe the auto-generated Pod and WebID should remain restricted to solid-tetris.com. Allowing users to save data from another domain like my-solid-recipe.com directly into their solid-tetris.com Pod would create confusion and feels unintuitive.

We were aiming for the second solution, which is already on our roadmap: once users become familiar with Solid, they can migrate their data from the demo app to their own Pod. Exporting data or settings from one app to import them into another is a common, well-understood user flow, and I believe it's the most intuitive and effective upgrade path.

Regarding the third option, we hadn't considered it before, but it is indeed intriguing. However, implementing it would require a broader initiative, perhaps something along the lines of adapting @michielbdejong's Remote Storage project to integrate seamlessly with Solid.

[jg10-mastodon-social]

Thanks for the reply!

I understand your position on Option 1. It's previously come up that while an app developer might be ok hosting e.g. game data and recipes, they might not want to also become responsible for e.g. health and finance data.
Given the suggestion on solid-practitioners to add this functionality to solidcommunity.net, it's worth pointing out that Option 1 is still viable there.
If a third party server is willing to become the default storage, then this flexibility could be permitted.

Incidentally, if the intention is to tie use of the storage to a single app, then I think the redirect path actually needs to be hard-coded. At the moment I can log-in to arbitrary apps as long as the redirect path matches the forgeRedirectUrl pattern (i.e. it's at the origin).
Given the possibility of using Option 1 in other cases, it would be great if the hardcoded redirect url was specified in the config and when absent, then the client's redirect url was used instead of forgeRedirectUrl.

Great to hear migration is already on your roadmap!

My understanding is that Remote storage's interoperability is primarily client side, i.e. it exposes the same js interface for multiple backends.
My suggestion here, which I think is consistent with Noel's proxy server idea, would be for the CSS instance itself to implement GitHub or Google Drive as a backend. The client just sees a Solid storage and CSS handled everything else in the background.
If the user is already signed in to e.g. GitHub, then presumably the same credentials would then be used to save to GitHub instead of local storage or a sparql endpoint.

[thhck]

It's previously come up that while an app developer might be ok hosting e.g. game data and recipes, they might not want to also become responsible for e.g. health and finance data.

+1

Given the suggestion on solid-practitioners to add this functionality to solidcommunity.net, it's worth pointing out that Option 1 is still viable there.
If a third party server is willing to become the default storage, then this flexibility could be permitted.

You right, there is two use case:

1. solid-tetris.com and solid-recipe.com both have their own CSS instance with this component
2. solid-tetris.com and solid-recipe.com both rely on solidcommunity.net to provider SSO login ( and creation of Pod and WebId )

This component was initially designed with the first use case in mind. However, the second use case is interesting from a Solid adoption perspective. It introduces security considerations that require more evaluation. For now, let's say the component is made for the first scenario, but I'll exploring the feasibility of the second .​

Incidentally, if the intention is to tie use of the storage to a single app, then I think the redirect path actually needs to be hard-coded.

Do you mean for security reason or other ? security wise, allowed client needs to be harcoded ( see #5 ) and this is WIP ( we hardcode the client_id tho, not the redirect_url , but we fetch it from the client )

At the moment I can log-in to arbitrary apps as long as the redirect path matches the forgeRedirectUrl pattern (i.e. it's at the origin).

WIP #5

Given the possibility of using Option 1 in other cases, it would be great if the hardcoded redirect url was specified in the config and when absent, then the client's redirect url was used instead of forgeRedirectUrl.

Okay I think I can work with that, feel free to open a PR or a feature request issue. But I would still need to forge the redirect url to add the code and other params..

My suggestion here, which I think is consistent with Noel's proxy server idea, would be for the CSS instance itself to implement GitHub or Google Drive as a backend. The client just sees a Solid storage and CSS handled everything else in the background.

Interesting concept, in that scenario this component could facilitate the provision of access tokens.

[jg10-mastodon-social]

Do you mean for security reason or other ? security wise, allowed client needs to be harcoded

The security issue is that you'd like to restrict access to a single client, similar to the way OAuth and OIDC usually work, whereas Solid is designed to allow any client to request consent.
So it's not necessarily a malicious app that would try to do this, but yes, there's currently a way to bypass your intended restriction. I'll have a look at the PR.