Why can't I login to this forum with my WebID?

TL;DR: It is completely doable, and we’ll be adding support soon!

Solid uses OIDC (OpenID Connect) for user authentication. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, and is widely supported. As a result, you’re going to start seeing “Login with Solid” here, and in many other places as well very soon!

While Discourse (the software that powers this forum) supports OAuth 2.0 out of the box, they didn’t include OIDC. That said, there are several projects on Github that have added OIDC support for Discourse that we’re looking at.

Stay tuned!



Please share links you have to any OpenID Connect (OIDC) related projects you’ve encountered for Discourse.

We are keen to implement that too as part of general OIDC related work.


This was the one I had earmarked to go back to and play with:


It was forked from the discourse oauth2 plugin - which I think is a good start. It’s a couple of years old, and built against a dated omniauth-openid-connect, so likely it would need a bit of tuning to work. I haven’t spent more than 30 seconds checking out the source but worthy of a bit of additional investigation.

We are having issues with the basic OAuth2 plugin i.e., it doesn’t appear to handle different identities i.e., everyone is pegged to the first authenticated user etc.

Will take a look at this other effort.

1 Like

Awesome - glad you guys are interested in looking into this as well.

Since the one I proposed was created as a fork of the basic discourse oauth2 plugin it must have the same issues you’re describing. Not sure if you’ve already had a head start trying to remedy that, but if you did we could try to incorporate that here as well.

1 Like

You can easily track what we are doing via our community server, just look at the authentication protocol options presented when you login.

The OAuth2 option appears to work, but it is actually broken in regards to actual identity mapping etc…

Still investigating what’s amiss.

1 Like

I’m confused, because here it says Solid uses WebId-TLS for authentication:

node-solid-server can be configured in two modes:

  • default: WebID-OIDC (which supports username/password and client certificates)
  • legacy: WebID-TLS (client certificates)

OIDC is a delegation-based protocol. So the following is a typical flow:

  1. You are on https://example.org/ and click “log in”
  2. https://example.org will ask who your identity provider is
  3. You reply that you want to log in through https://my.identity.pod/
  4. https://example.org/ redirects you to https://my.identity.pod/
  5. You log in on https://my.identity.pod/ with your preferred login method (with node-solid-server, that is either username/password or a client certificate)
  6. Based on that login, https://my.identity.pod/ determines your WebID
  7. https://my.identity.pod/ redirects you back to https://example.org/, and tells https://example.org/ your WebID
  8. You are now logged in on https://example.org/ as your WebID through https://my.identity.pod/

The above is the full explanation. So can node-solid-server use WebID-TLS? Yes, but it is wrapped inside of WebID-OIDC. The legacy native WebID-TLS mode is being deprecated.


Issue fixed, i.e., you can get to an OAuth Provider (e.g., one of ours which leverages OIDC). The only issue right now is getting the routing to a solid pod working (status: WIP).

Great! Let me know if anything we can do from the solid side to assist.

I don’t endorse the legacy mode tag. It is unnecessary.
If someone seeks to deploy in WebID-TLS mode, they should be able to do that, forever.

Note, I say this understanding fully well that OIDC-mode instances include a TLS-bridge via “popup.html” and (if using our NSS variant) an ability to interact via curl using a custom "webid: " request header that takes “yes” as a value.

Fundamentally, good technology should be flexible enough for users to make educated selection choices. It shouldn’t force anything.