Dear all,
I was running the Solid community server locally and I was wondering if it is possible to replace the way of authenticating as it is now (name, password) with an identity provider of my choice who is implementing the OIDC flow. Not a solid pod (identity) provider but say Google or Itsme or whatever for that matter.
If yes, how do I configure this locally and where in the community code should I start looking? Thanks!
Kind regards,
Frederik
After a first investigation, I would say for instance for Google I could add the “log in with google” on the page register-partial.html.ejs. That will then do the authentication and return a google id token. That I need to send to the server and in Registration manager I will have to add the web-id as custom claim for the user. This means I need to replace the accountStore in the RegistrationManager, because it only works with email/password. In the loginHandlerI then need to call the verify of Google IDP to verify the user and get the web-id. Or is there another way? Do I need to create a new account store interface and configuration via json-ld?
The community server does already allow use of another server implementing the solid-oidc flow, e.g. through the setup screens.
However it’s worth noting that solid-oidc is an extension of oidc, so what you’re asking is rather advanced and requires detailed understanding of the solid-oidc spec (as well as, e.g. Google’s own requirements).
You might also find this thread useful: Login to a SOLID Pod from a Flutter app - #8 by zwifi
Having had another look, I’d say you would indeed have to implement a vanilla OIDC authentication backend for community solid server, which would need to be registered with Google as an app, and would in turn issue a webid for each Google login, to then be provided to apps and pods encoded in the DPoP access token.
Looks like Inrupt already provide a similar OIDC bridge service for enterprise users: Solid OpenID Connect Service — Inrupt Enterprise Solid Server
Presumably providing this kind of bridge publicly for any Google user might run into issues with their terms of use?
And if you’re only doing it for a few, you’re probably better off just using the built-in account store…?
That’s exactly the approach I would have recommanded. What you are describing here is called an “identity broker”, which is a known pattern in OpenID, described here for instance. In the diagram in this page, the “relying party” (an app in OpenID talk) is a regular server-side Web application from the point of view of the underlying OIDC issuers, such as Google, and it is the Solid-OIDC issuer from the point of view of the Solid applications.
Presumably providing this kind of bridge publicly for any Google user might run into issues with their terms of use?
As far as I can tell, since you’re basically building a regular app authenticating its users against the Google OIDC endpoint, there’s no reason why they would disapprove that.
As @josephguillaume mentioned, implementing such a broker requires a good understanding of the Solid-OIDC specification. You’ll need the broker to support the extensions to the OIDC specification brought by Solid-OIDC.
Thanks! If I understand correctly, if I have a community server, where I replace register and login with username/password by “login with Google” and I register my localhost with Google to receive a client-id and client-secret, than I can keep all other flows to my local community server intact. Which means I can have a random solid client to get the information on my pod server via my local IDP which is implementing the Solid-oidc, but to login I depend on the Google IDP, where I verify the token returned from Google to the web page by calling the verify function from Google with the token on my community Solid server. Upon verification correct, I can retrieve the stored web-id and return it.
I will give this a try.
The only thing that bothers me, is that you can only register 1 pod with one email address per server, am I correct?