Decision: how we do authentication with the sync server

[nikgraf]

Since we plan to run sync servers for developers they would not have the same host as their frontends. This rules out cookie authentication since Safari blocks third-party cookie since a while.

This leaves us with all sorts of authentication methods described here: https://fly.io/blog/api-tokens-a-tedious-survey/

Privy offers JWTs https://docs.privy.io/guide/react/authorization which might be the easiest to get up & running quickly, but really want to avoid JWTs on the long rung or at least have a better option once we offer custom identity management that is not tied to Privy.

[pcarranzav]

Eventually a gateway could help a developer find a suitable sync server from a decentralized set of providers and provide payment abstraction (with providers being paid in a trust-minimized way on-chain). So developers would pay through a gateway like with other data services on The Graph, ideally whatever pattern we follow here is similar or can be adapted to work in a similar way to that.

For subgraphs, we currently use API keys / bearer tokens that devs create in a settings page on the gateway and then embed into their apps - these can have usage limits and can be expired. Obviously that's not necessarily the optimal solution for a local-first app, but could be a workable starting point? (we can look with a bit more detail at how exactly those tokens are created on subgraph studio, I only know this at this high level)

[nikgraf]

Makes all sense!

Here I rather meant auth from a user/client perspective to a sync server. How does the the sync server authenticate that the request came from user X.

So we possibly need 2 tokens?

[pcarranzav]

Yeah, I guess we'll need some form of "payer token" separate from the user token, but we can cross that bridge when we work on how the sync server service is paid for.

For user tokens, and going through the list you linked to, there's two options that sound appealing to me:

• A) simple random tokens: I don't think we need any of the bells and whistles from OAuth, JWT or any of the others, do we? so we could just generate a random token for each user, and send it when the user logs in, either by validating the Privy JWT once or asking the user to sign a message (ideally using SIWE?). Most of the interactions would happen over the websocket after logging in once, so there should be no performance impact from fetching the token from the DB.
• B) authenticated requests: since we're generating a signing key for each user, we could just use that. The user would sign the message that creates the keys with their wallet, and after that all messages are signed with the signing key.

Option A is a bit simpler, and there might be some performance impact from signing and verifying signatures for everything, so I would go with that for now, wdyt? I can implement it together with #4

[pcarranzav]

BTW, the way to find the address (which is what we want to use as account ID, right?) using Privy requires using the identity JWT that is, as far as I can tell, only exposed through cookies (there's also an API endpoint but it's deprecated). So it looks like even with Privy it could make sense to use SIWE. (Unless we wanted to identify users by their Privy DID, but that locks us in with Privy more)

[nikgraf]

SIWE looks perfect! Glad there is a standard solving this issue 👍

Usually I'm very cautious with signing as auth since if not done right (like in SSH v1 https://www.coresecurity.com/core-labs/advisories/ssh1-crc-32-compensation-attack-detector-vulnerability), you open up to security vulnerabilities. I'm confident a standard has considered this.

[pcarranzav]

Some things I'm realizing as I make progress:

1. Storing keys and tokens in local storage makes this vulnerable to XSS. I'm not sure if there's a better way to do this though... HttpOnly cookies could work for the token (maybe we could use it just for a refresh token, and use a short lived auth token in local storage?). Afaict if we use SameSite=None; Secure the browsers shouldn't block them. I'm not sure what to do about the encryption keys though, because we do need to use these client side.
2. Similarly to the XSS issue, the token and keys are vulnerable to a malicious app taking the user's identity and impersonating the user in other apps. This makes me think the auth token and the keys should be namespaced per-app, so that each app client only has access to its own relevant private data.

(I'll probably still proceed with the current plan in #64 to get to a POC quickly, but we should address these before shipping)

[nikgraf]

Storing keys and tokens in local storage makes this vulnerable to XSS. I'm not sure if there's a better way to do this though... HttpOnly cookies could work for the token (maybe we could use it just for a refresh token, and use a short lived auth token in local storage?). Afaict if we use SameSite=None; Secure the browsers shouldn't block them. I'm not sure what to do about the encryption keys though, because we do need to use these client side.

Safari already started blocking all 3rd party cookies afaik. At least I experimented with the idea earlier this year and couldn't get it to work. Also Chrome is heading towards this route. Afaik there is no solution to this problem except if you proxy the backend through your own domain (and with Websockets that's a nightmare …)

Similarly to the XSS issue, the token and keys are vulnerable to a malicious app taking the user's identity and impersonating the user in other apps. This makes me think the auth token and the keys should be namespaced per-app, so that each app client only has access to its own relevant private data.

Yeah, that's a topic I also brought up in the schema discussion. On one hand it's your data and different apps should be able to access your data so you can work with it. On the other hand we have no definition of how permissions can/would look like. Super curious to explore this further as this will be quite essential to get right.