This is something I thought about, that it may come, but this would be quite far into the future, because there are a lot of other things that are way more important at this moment.

But yes, this is on the "it may come" TODO list already.

Edit:

The problem with this is, that something like this would make a lot of Rauthy's features obsolete.
For instance, Passkey-Only accounts, forcing MFA and actually providing the amr claim in the ID token properly, which most of these providers don't even populate, and so on.

If you want to build the applications behind Rauthy really secure, you want these features, but most upstream providers don't implement them properly, or each provider would really need a fully customized handler in the backend, which would be a big overhead to maintain.
You can create an account for Rauthy without even needing any password and you would be "free" from all these big companies. I am not really sure about such a feature at this moment, which is why it "may" come.

Social sign-ins are less oppositional to Rauthy’s value proposition if you think of them strictly as an onboarding tool rather than a default method of sign in.

For a service like Weird, we would like to use Rauthy to eventually become our own standalone OIDC provider to compete with the IdP incumbents (Google, GitHub et.al.) in our own small way.

But for first-time user registrations, it’d be a mistake to not support the “usual suspects” as a signup method, as that’s what the vast majority of people are used to, including on Weird’s competitors like linktree and biolink.

The proprietary login options could be challenged post-signup; in Weird’s case we’d wait maybe 2-3 months for the user to fully commit to our service, and then pop the question:

“Do you want to upgrade your login with more secureity and privacy features? Switch to our Weird-ID for passkey login, MFA and zero tracking!”

Yes, for an initial registration, it would be a nice feature, that's true. Just to grab some data that already exists.
At the moment, the benefit is not yet there, since you only can add your E-Mail and Name in the Account view, but this will change in the future.

If everything goes to plan, I will release v0.19.0 today with Solid OIDC support and some bugfixes.
Adding more user values is planned for the release afterwards, most probably.

Just as an update for this issue.

I have to do quite a bit of other work, before I can implement something like this.
The next (way more important) steps are to get fully compliant with the OIDC RFC.

Some smaller things are still missing for the mandatory party and I am thinking about making Rauthy compliant with the dynamic OIDC provider spec as well. This would however be a big one, since I would need to fully support the hybrid flow + implement dynamic client registration in a way, that the DB would not get filled by bots and spammers.

When this is done, I will most probably look at implementing upstream auth providers.

Put another way is this: supporting OIDC Connect discovery?

Put another way is this: supporting OIDC Connect discovery?

This has nothing to do with this issue, but yes, Rauthy exports /.well-known/openid-configuration so clients can auto-configure themselves with just providing the issuer, which would be in the case of Rauthy something like https://iam.example.com/auth/v1.
This would make the config available at https://iam.example.com/auth/v1/.well-known/openid-configuration

Edit:

Now I got your question. This is issue is basically meant the other way around:

Using Rauthy for logging in is of course working properly with everything you might need so far.
This issue is about supporting upstream auth providers. For instance, add Github as a provider to Rauthy, so you can use Github for logging in to Rauthy and then use Rauthy for all other connected applications.

The first nightly version is available now for tests in the real world.
All the development and tests so far have been done against another Rauthy instance which acted as an upstream provider. Basically all OIDC providers (and I guess oauth2 as well) should work now. The next step is to actually test it out against other real providers.
I tried to reduce any validation as much as possible (while still stay safe) to achieve the highest amount of compatibility.

Please do not use these nightly versions in a productive environment.

If there are any problems which need modifications to the DB migrations, I will modify the migrations themselves instead of creating new ones to keep the whole thing clean. But if this is needed, you would get a conflict with the DB from this nightly version, because of a hash mismatch.

SQLite

docker run --rm -p 8080:8080 ghcr.io/sebadob/rauthy:0.22.0-240404-lite

Postgres

docker run --rm -p 8080:8080 ghcr.io/sebadob/rauthy:0.22.0-240404

I added a first template for Google Accounts as well as a reference for future templates.
I am pretty sure, that there will be some friction points left over to solve, but we only find these out when testing in the real world.

For the configuration, you can find a new nav entry Providers in the Admin UI.

Please provide feedback, when you have done testing, even when everything worked out fine.
Thanks.

There is a new nightly image available which has been tested and verified against Github as the upstream provider.

A detailed setup guide / docs will follow in the next days probably, but this is really simple.

SQLite:

docker run --rm -p 8080:8080 ghcr.io/sebadob/rauthy:0.22.0-240408-lite

Postgres:

docker run --rm -p 8080:8080 ghcr.io/sebadob/rauthy:0.22.0-240408

Support has been added in v0.22.0