Support Sign In With Solana (SIWS)

[metasal1]

Feature Request: Integrate Sign In With Solana into Supabase Auth

Overview

Add support for Sign In With Solana (SIWS) as a new authentication provider in Supabase Auth, allowing users to authenticate using their Solana wallets through a standardized, secure protocol.

Motivation

1. Enhanced Security: SIWS provides a more secure authentication flow than traditional connect + signMessage methods by standardizing message formats and shifting message construction responsibility to wallets.
2. Improved UX: Replaces the multi-step connect + signMessage flow with a single signIn operation.
3. Growing Ecosystem: Solana has a large and growing ecosystem of dApps and users who would benefit from this integration.
4. Standardization: SIWS follows similar principles to Sign In With Ethereum (EIP-4361) while extending capabilities for the Solana ecosystem.

Technical Implementation

Required Changes

1. Add SIWS provider configuration:

GOTRUE_EXTERNAL_SOLANA_ENABLED=true
GOTRUE_EXTERNAL_SOLANA_REDIRECT_URI=http://localhost:3000/callback

2. Implement new auth endpoints:

• /authorize?provider=solana
• Handle SIWS callback with signature verification

3. Add SIWS message handling:

• Message construction following ABNF format
• Verification of signatures using ed25519
• Domain binding for security

Integration Points

1. Update Supabase Auth to handle SIWS signIn output:

interface SolanaSignInOutput {
  account: WalletAccount;
  signedMessage: Uint8Array;
  signature: Uint8Array;
  signatureType?: "ed25519";
}

2. Add Solana wallet provider support in auth client libraries

Security Considerations

• Implement domain binding to prevent phishing attacks
• Add signature verification using Solana's ed25519 curve
• Support refresh token rotation for enhanced security
• Add rate limiting for sign-in attempts

Dependencies

• @solana/wallet-standard-features: ^1.1.0
• @solana/wallet-standard-util: ^1.1.0

Success Metrics

• Number of applications using SIWS authentication
• Reduced authentication-related support tickets
• Improved conversion rate on sign-up/sign-in flows

Future Considerations

1. Support for multiple Solana wallet providers
2. Enhanced error handling for various wallet states
3. Integration with Supabase RLS policies

[kiwicopple]

one of the main objectives here is to provide one of our larger customers the ability to use SIWS with Realtime +AuthZ, so a demonstration of that capability would be great 👍

[hf]

Hey I'm on the Auth team and wanted to share some ideas as to how this should be implemented in the server to hopefully minimize back-and-forth and have something that can be maintained by the team long term.

First off, Supabase Auth does not have hosted pages nor will it in the mid-term. Please base the implementation around this limitation.

Given that both SIWS and SIWE (and all other semi-failed web3 protocols) rely on verifying a signed message by the wallet it would be best to follow these guidelines:

1. POST /token?grant_type=siws You'd send it a JSON body with the signed SIWS/SIWE message to be verified by the server. The message is obtained out-of-bounds. This should translate to a JS API like supabase.auth.signInWithWeb3({ siws: await walletSignIn() }). This API then would be replicated by the officially supported client libraries.
2. Use the createAccountFromExternalIdentity function to set up the identity of the user.
3. Avoid adding a new column to auth.users table. Store the address in the auth.identities table.
4. Linking with other identities can be done as it is today.

[hf]

I'd prefer it if there was minimal to no dependency on third-party libraries. We're already struggling with support and maintenance of core libraries, so anything new should pass this test:

1. Is it mostly finished software? (Small surface area, minimal API, focused design.)
2. Does it have high coverage? Over 60% preferrable.
3. Does it have tagged versions? If there are no tags, the likelihood of something being accidentally upgraded with a supply-chain attack increases.
4. Is it backed by a company or a large community?
5. Is it abandonware? Check for automated tools that close off issues making it look like there's activity when there isn't.

[nickfrosty]

Thanks for sharing the info here. I think it will be super helpful for someone within the Solana ecosystem to get a better understanding of what the expect when implementing.

re minimal dependensies: this should not be too much of a problem. The SIWS spec is fairly simple under the hood since its basically parsing a standard plaintext message and validating a ed25519 signature

[Bewinxed]

Hi, I built @DeAuthXyz , a solana oauth solution which won a solana hyperdrive hackathon, I’m very well versed in this, I’m taking a look now.

[awalias]

Looks good guys!

can we built this so that that it supports more chains? or so that we can at least extend it later a la

SIWS follows similar principles to Sign In With Ethereum (EIP-4361) while extending capabilities for the Solana ecosystem.

so that we don't end up with separate implementations for each and a long list of:

GOTRUE_EXTERNAL_SOLANA_ENABLED=true
GOTRUE_EXTERNAL_SOLANA_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_ETH_ENABLED=true
GOTRUE_EXTERNAL_ETH_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_X_ENABLED=true
GOTRUE_EXTERNAL_X_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_Y_ENABLED=true
GOTRUE_EXTERNAL_Y_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_Z_ENABLED=true
GOTRUE_EXTERNAL_Z_REDIRECT_URI=http://localhost:3000/callback

[Bewinxed]

Looks good guys!

can we built this so that that it supports more chains? or so that we can at least extend it later a la

SIWS follows similar principles to Sign In With Ethereum (EIP-4361) while extending capabilities for the Solana ecosystem.

so that we don't end up with separate implementations for each and a long list of:

GOTRUE_EXTERNAL_SOLANA_ENABLED=true
GOTRUE_EXTERNAL_SOLANA_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_ETH_ENABLED=true
GOTRUE_EXTERNAL_ETH_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_X_ENABLED=true
GOTRUE_EXTERNAL_X_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_Y_ENABLED=true
GOTRUE_EXTERNAL_Y_REDIRECT_URI=http://localhost:3000/callback
GOTRUE_EXTERNAL_Z_ENABLED=true
GOTRUE_EXTERNAL_Z_REDIRECT_URI=http://localhost:3000/callback

In my own apps I do it like /callback/[provider]?chain=[slug/net]

so for example it would be
/callback/eip4361?chain=solana-mainnet
/callback/eip4361?chain=solana-mainnet

So in your case I guess it would be GOTRUE_EIP4361_ENABLED=true

then you would have another variable, perhaps GOTRUE_EXTERNAL_EIP4361_CHAINS=solana-mainnet,ethereum-mainnet,ethereum-testnet etc...

e.g

# EIP-4361 OAuth config
# EIP-4361 OAuth config
GOTRUE_EXTERNAL_EIP4361_ENABLED="true"
GOTRUE_EXTERNAL_EIP4361_STATEMENT="Sign this message to verify your identity"
GOTRUE_EXTERNAL_EIP4361_VERSION="1"
GOTRUE_EXTERNAL_EIP4361_TIMEOUT="300s"
GOTRUE_EXTERNAL_EIP4361_DOMAIN="localhost:9999"
GOTRUE_EXTERNAL_EIP4361_REDIRECT_URI="http://localhost:9999/callback"

# Supported Chains Configuration
GOTRUE_EXTERNAL_EIP4361_SUPPORTED_CHAINS="ethereum:1,ethereum:137,solana:mainnet,solana:devnet"
GOTRUE_EXTERNAL_EIP4361_DEFAULT_CHAIN="solana:mainnet"

How would you prefer it? because even if the standard for Auth is the same, there are some other handlers (for getting accounts, perhaps getting the onchain profile picture (or support for ENS domains such as .eth)) which are different for every chain.

So the callback would preferably need some sort of query parameter for the chain or it can be stored in the auth request (i'm still checking out the auth lib)

[Bewinxed]

Hello, I've built a minimal example, not sure if i should submit a PR or discuss here first:

https://github.com/Bewinxed/auth

# EIP-4361 OAuth config
GOTRUE_EXTERNAL_EIP4361_ENABLED="true"
GOTRUE_EXTERNAL_EIP4361_STATEMENT="Sign this message to verify your identity"
GOTRUE_EXTERNAL_EIP4361_VERSION="1"
GOTRUE_EXTERNAL_EIP4361_TIMEOUT="300s"
GOTRUE_EXTERNAL_EIP4361_DOMAIN="localhost:9999"

# Supported Chains Configuration
GOTRUE_EXTERNAL_EIP4361_SUPPORTED_CHAINS="ethereum:1,ethereum:137,solana:mainnet,solana:devnet"
GOTRUE_EXTERNAL_EIP4361_DEFAULT_CHAIN="ethereum:1"

since siws/siwe use eip4361, i added the grant type eip4361, which can extend eth/sol and any compatible network, which can be specified in the .env

then based on the chosen network e.g solana:mainnet the appropriate validation will be used.

I've implemented a siws package inside internal/utilities/siws that implement many of the necessary siws functions (need to review them to double check the validations).

for solana, I tried a no-dependency validation however i added the btc base58 package

as for ethereum, I'm, using the ethereum-go package, which is widely supported, but perhaps we can omit and try to implement a native validation without the dep.

In the root folder, there is a external_eip4361_siws_example.go
uncomment the last 3 lines and run it using go run and it will provide an example SIWS message you can test.

built it, spun up the server:

await fetch("http://localhost:9999/token?grant_type=eip4361", {
    method: "POST",
    headers: {
        "Content-Type": "application/json"
    },
    body: JSON.stringify({"address":"J79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3","chain":"solana:mainnet","grant_type":"eip4361","message":"localhost:9999 wants you to sign in with your Solana account:\nJ79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3\n\nSign in with your Solana account\nURI: https://example.com\nVersion: 1\nNonce: 90cf4f06e021297d80363477774ce7f7\nIssued At: 2025-01-17T18:30:31Z\n","signature":"iWW0I/rbGwXwxj6v8oBTraQ39f84Oewo7bk7OyHwkwTx8FmswtpU+eR4gAZGrqRtrEDtXyFPuDbmYZzoEz2DDg=="})})
    .then(response => response.json())
    .then(data => console.log("Response:", data))
    .catch(error => console.error("Error:", error));
    ```
    
    response:
    ```json
    {
    "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIzNzJiMmZiYi02YTM4LTQ4ZTUtOWQ0ZC0xOGJlMzMwMjFjYTIiLCJhdWQiOiJhdXRoZW50aWNhdGVkIiwiZXhwIjoxNzM3MTQyMzc2LCJpYXQiOjE3MzcxMzg3NzYsImVtYWlsIjoiIiwicGhvbmUiOiIiLCJhcHBfbWV0YWRhdGEiOnsicHJvdmlkZXIiOiJlaXA0MzYxIiwicHJvdmlkZXJzIjpbImVpcDQzNjEiXX0sInVzZXJfbWV0YWRhdGEiOnsiY3VzdG9tX2NsYWltcyI6eyJhZGRyZXNzIjoiSjc5Zm5CSkdQZWl6SE5ZUjFBR3FSRlJpV01RQUVKTE51M2VQb1NXQTdaYjMiLCJjaGFpbiI6InNvbGFuYTptYWlubmV0Iiwicm9sZSI6ImF1dGhlbnRpY2F0ZWQifSwiZW1haWxfdmVyaWZpZWQiOmZhbHNlLCJwaG9uZV92ZXJpZmllZCI6ZmFsc2UsInN1YiI6InNvbGFuYTptYWlubmV0Oko3OWZuQkpHUGVpekhOWVIxQUdxUkZSaVdNUUFFSkxOdTNlUG9TV0E3WmIzIn0sInJvbGUiOiJhdXRoZW50aWNhdGVkIiwiYWFsIjoiYWFsMSIsImFtciI6W3sibWV0aG9kIjoid2ViMyIsInRpbWVzdGFtcCI6MTczNzEzODc3Nn1dLCJzZXNzaW9uX2lkIjoiMTY0NWU4MTItMzE0OC00Mjg2LTljOTItNzQyNGE0OGM3OWMzIiwiaXNfYW5vbnltb3VzIjpmYWxzZX0.yizc-IeK73DDz8xw3UBO_pLI8a_ttjldAuDokCF8y_k",
    "token_type": "bearer",
    "expires_in": 3600,
    "expires_at": 1737142376,
    "refresh_token": "J2EY1jvVd2SF343fIgVwyw",
    "user": {
        "id": "372b2fbb-6a38-48e5-9d4d-18be33021ca2",
        "aud": "authenticated",
        "role": "authenticated",
        "email": "",
        "email_confirmed_at": "2025-01-17T21:30:41.607863+03:00",
        "phone": "",
        "confirmed_at": "2025-01-17T21:30:41.607863+03:00",
        "last_sign_in_at": "2025-01-17T21:32:56.1850242+03:00",
        "app_metadata": {
            "provider": "eip4361",
            "providers": [
                "eip4361"
            ]
        },
        "user_metadata": {
            "custom_claims": {
                "address": "J79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3",
                "chain": "solana:mainnet",
                "role": "authenticated"
            },
            "email_verified": false,
            "phone_verified": false,
            "sub": "solana:mainnet:J79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3"
        },
        "identities": [
            {
                "identity_id": "567bf4c0-65f4-4917-aa35-96a80b6fcc5c",
                "id": "solana:mainnet:J79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3",
                "user_id": "372b2fbb-6a38-48e5-9d4d-18be33021ca2",
                "identity_data": {
                    "custom_claims": {
                        "address": "J79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3",
                        "chain": "solana:mainnet",
                        "role": "authenticated"
                    },
                    "email_verified": false,
                    "phone_verified": false,
                    "sub": "solana:mainnet:J79fnBJGPeizHNYR1AGqRFRiWMQAEJLNu3ePoSWA7Zb3"
                },
                "provider": "eip4361",
                "last_sign_in_at": "2025-01-17T21:30:41.589565+03:00",
                "created_at": "2025-01-17T21:30:41.590111+03:00",
                "updated_at": "2025-01-17T21:30:41.590111+03:00"
            }
        ],
        "created_at": "2025-01-17T21:30:41.579424+03:00",
        "updated_at": "2025-01-17T21:32:56.19047+03:00",
        "is_anonymous": false
    }
}

[Bewinxed]

PR Submitted supabase/auth#1918