quali-chat / siwe-oidc

OpenID Connect Identity Provider for Sign-In with Ethereum.
https://oidc.login.xyz
Apache License 2.0
0 stars 0 forks source link

OIDC: Evaluate SIWx #4

Open thepiwo opened 4 months ago

thepiwo commented 4 months ago

Evaluate if SIWx can be a good choice to handle the authentication with different blockchains.

Useful resources:

thepiwo commented 4 months ago

@michele-franchi converted this to an issue to properly add some comments:

CAIP-122: Sign in With X (SIWx) defines a standard protocol with which arbitrary chains can use a keypair-signature based login mechanism, this is purely off chain, based on and compatible with SIWE

The standard doesn't include any specification regarding wallet connection. This siwe-oidc repository uses another package to fullfill the Ethereum wallet connection part, then uses the SIWE protocol to get the users signature for login purposes and wraps this to be used with the OIDC server protocol for generic login use.

So there is 3 parts to the login flow

  1. OIDC server protocol (where this wrapper provides a rust server implementation and we've in the past written our own server based on https://github.com/panva/node-oidc-provider to fullfill other requirements)
  2. SIW(E/X) the login signature protocol that the user can be prompted with
  3. the wallet connection

The referenced SIWx repository provides a wrapper for different blockchains to provide the signature (flow 2.) and provides example implementations for select wallet interactions (not generic as we need, flow 3.). Overall probably more serving as an example for developers rather than a maintained ready-to-be-used software.

thepiwo commented 4 months ago

@michele-franchi so my recommendation on what to implement would be the following.

for now we can keep using this already working siwe-oidc provider and use it as is. When we decide what other chain to integrate we should

then in later steps if we have one or multiple addional chains implemented we can also move the SIWE provider to use our commonly shared new provider, then eventually run multiple separate provider deployment of the same code (different config for different chain) or one shared provider deployment to connect to all chains.

thepiwo commented 4 months ago

also attaching our previous discussion on this for the record here: image