Community Infrastructure SIWE Upgrade

Technical
#1

This forum post is a submission for the Discourse Ethereum authentication bounty.

My solution was to implement Sign-In With Ethereums OpenID Connect Provider for use by the Tornado Cash (TC) community, similar to running TC community managed IPFS gateway. Please start by reading the introduction section of this repo for a full description of the service, what it is, why it exists, how it works, etc. By using this method it not only allows TC to integrate Ethereum wallet account authentication for Discourse, it makes it relatively simple to implement across all existing infrastructure using the commonly supported standard called OpenID Connect, an extension of OAuth2.

From the bounty description:

Integrate the possbility of registering and signing into an account on a Discourse instance by connecting an Ethereum wallet, and signing a message. Display the user’s verified address on their forum profile.

My submission matches the above with the following caveat. A user’s verified address is not displayed publicly but is viewable to them in their profile, they can choose to reveal it upon account creation or at a later date.

Regarding:

It should be not be understated, that implementations that depend on other services are not desirable.

My solution implements a self-hosted service and touches no external resources not owned/managed by the TC community. As I believe that was the intent, to avoid external services to preserve privacy, this service would run along side any of the existing TC services, Discourse included.

Of the outlined deliverables:

  1. Fork the Discourse source code
  2. integrate logic to handle a web3 provider
  3. on registration and sign in require a message to signed to prove owneship of the address in question
  4. Replace email key mappings in the database store with Ethereum addresses
  5. Create a repository on the community git and document the logic thoroughly
  • #5: I have documented both the installation of the service and how to connect it to all the existing TC infra. services.
  • #2 & #3: Both are implemented as described
  • #4: Was not met because of #1
  • #1: Forking and building a custom Discourse image, while opensource, seems to have been made deliberately difficult if not near impossible. See below for more context.

While speaking with Micah in the matrix general chat he corroborated the difficulties I experienced when trying to build the base Discourse app from source, without any modifications. Linking me to this thread. Reading through more thread of people trying tweak Discourse the dev team seems to not at all be receptive.

Instead of forking Discourse to implement a custom solution I made use of existing plugins to implement an already widely used standard that Discourse, and many other services, support.

To see a demo of this infrastructure in action I have them hosted at the following subdomains for testing purposes:

NOTE: The current SIWE page where the message is signed is the default one shipped by the dev team. It shows options for several wallet providers. Currently only MM is supported as the other require api keys to use. This page can be forked and modified, far more easily than discourse, to the desires of the community.

1 Like
#2

I broke my test server while trying out a mastodon install. Not sure why it broke everything but it did.

Will do a reinstall sometime tomorrow.

#3

Forgot to update, but the demo domains are back up and operational for viewing.

#4

While this implementation is long-winded I think it truly sets up an accessible system for authentication across communal infrastructure, obviously still retaining the possibility of legacy logins. Your submission exceeds the expected deliverables of purely developing a solution for forums logins - and support across the git instance and matrix chat given the adoption of the OpenID standard.

While this is possible, proper precautions should be undertaken before such decision as identity hijacking for crucial resources such as; source code - are a real threat with the deployment of a localised authentication provider.

Upon reviewing your submission - which was incredibly well documented and structured - I came across
some standard security recommendations for the standard by a security researcher.

The source code developed by spruce id seem to address adhere to mitigating the well known attack vectors, such as inlcuding nonce and state parameters to ensure safe user-client identification from replay and cross-site scripting attacks.

During integration I noticed that spruceid that email scope permissions are unsupported by default, this obviously caused conflict in the userflow of the login and register processes - as email input was still required. I took the time to modify basic support for the email scope, permit email modification of a user that registers using a wallet, to map emails in the following format of

<ADDRESS>@tornadocash.community

This ensures a smooth login expierence, currently there is no support for connecting your wallet for legacy accounts as some planning needs to be done to support backwards integration with no conflicts.

1 Like
#5

Glad to hear the documentation was up to standard! Tried to be as thorough as possible.

That gitbook is great, definitely will take some time to review it in more detail. When I was first setting up my test server I was just using the official docs and found it hard to navigate: Final: OpenID Connect Core 1.0 incorporating errata set 1

That’s an awesome improvement to the UX to be able to skip fudging an email on account creation. Great addition and I’m curious how you implemented that. Did you modify SpruceID OIDC server response in some way? Somewhere in this function? siwe-oidc/oidc.rs at main - siwe-oidc - tornadocash

It looks like they also added the ability to resolve Avatars last month so there might be a way to add at some point.

One other thing is that I noticed on my test server there’s a way for existing accounts that were created without SIWE to associate their account with one of their Eth addresses. This setting might be it: Discourse OpenID Connect - plugin - Discourse Meta

Once that’s enabled forum users could navigate to their user Preferences → Account → Associated Accounts