FIP: Farcaster "Quick Auth" Server

[deodad]

Title: Farcaster "Quick Auth" Server
Authors: @deodad

Abstract

Introduce a trusted server that verifies SIWF credentials and issues signed tokens to make integrating SIWF significantly easier.

Problem

Integrating Sign In with Farcaster into an application is significantly more difficult than existing integrating other social sign in providers like Sign In with Google. SIWF defines how to generate and resolve a signed credential to an identifier but developers still need to:

• securely generate, store, and consume nonces
• verify the SIWF credential, which requires making RPC requests to the get the latest state of Snapchain or Optimism and running up to date verification logic (for example, developers using auth-kit to verify credentials will need to manually upgrade to support auth addresses)
• a mechanism for authenticated sessions

The developer will also want this to be performant. Compare this to something like Sign In with Google that does the heavy lifting for you and returns a JWT you can validate against their server.

Specification

Implement an OSS service that verifies SIWF credentials and issues signed JWTs suitable for short-lived sessions. This service would available at a public host like auth.farcaster.xyz and also easily deployable for developers that would prefer to self host.

It would have 4 endpoints:

• POST /nonce to fetch a nonce
• POST /verify-siwf to verify a SIWF message and get a JWT
• GET /verify-jwt to verify a JWT (one off)
• GET /.well-known/jwks.json to fetch public key that signs JWTs to so verification can be done locally (optimized JWT verification for use on a server)

The JWT would include the user's FID, the domain the JWT is valid on, the issuer of the JWT, and an expiration time. Applications can verify this token with a single API call to the authorization server or verify it locally using [JWKS(https://datatracker.ietf.org/doc/html/rfc7517).

It's important to note that using this service is completely optional.

Integration with Mini Apps

The Mini App SDK signIn action can be extended such that applications can request a session token directly instead of the raw SIWF credential. The Farcaster client the mini app is running in would complete the SIWF flow with the authorization server and return a JWT to the Mini App that Mini App can use directly as a session token. By default the public server would be used to handle SIWF and issue a token but this could be overridden for developers choosing to self-host.

[stevedylandev]

Hell yes

[vrypan]

I like the self-hosted idea. I would vote against having a public one, because it sets the norm, and a few months down the road it has become a single point of failure, and an attractive target for attacks. If it something like "clone the repo, go to Vercel and deploy it", I think it's easy enough for everyone to setup. Plus, when you update your repo, your instance gets updated too.

[vrypan]

To take it further, this could be a repo that provides additional services devs will often want to use.

[sanjayprabhu]

I like it. The server should read the state from Snapchain so that we don't need to change anything when keys migrate to snapchain later.

We might need to have some protection against chain halts/out of sync nodes. Maybe monitor block delay and fail loudly if it's too high.

[andrei0x309]

I first thought moving the signers to Snapchain was a good move for performance, probably was one of the first people suggesting it, but the reality is more nuanced than I first thought.

Moving Advantages:

• better performance
• Snapchain does not need to sync anymore
• lower cost to do signer operations

Moving Drawbacks:

• Public optimism nodes you can find anywhere, so it is easier to submit a change
• lose querying capabilities at the contract level
• Signer API is more stable and public because it is dictated by the contract

The biggest drawback is the availability of doing signer operations, which will fall dramatically as the availability of public Snapchain nodes is non-comparable to Optimism nodes.

The biggest advantage is just the performance increase, as the cost of doing a signer tx on Optimism is many times less than 1 cent.

So yeah, it's nuanced....

[andrei0x309]

A public one is good for easy accessibility for devs, and it's the main idea of cutting costs, because there's no impediment to implement the above server by any party at this moment that does exactly what is described here.

It means no change is made with this FIP other than providing a helping tool for devs, which I don't see any reason not to do.

The only problem is that if this server will also work with JWT, the expire date should be set by the dev and not chosen by the server statically because, devs might have different use cases, sometime a short lives JWT is ok, but sometimes is ok to have a long lived one, the dev should be able to set custom expiration of JWT.

[horsefacts]

Supportive of this! Way back when, this was one idea for how the SIWF relay could work. Will see if I can dig up any of the old design docs.