Adding Auth to estuary-www

Working Groups Webnative Filecoin Integration
1

Existing Authentication

  • Password authentication through an API server (https://api.estuary.tech/login)
  • When signing in, the password is hashed client-side and sent to server
  • Estuary token and CSRF token stored as cookies in the browser

Existing Authorization

  • Authorization is checked in server rendered pages on each request
    • The ESTUARY_TOKEN is verified by the API server
      • On success, this returns some JSON representing the viewer
      • On failure, it returns null
    • If we have a viewer, the user is returned a page if they have access
      • Some pages are “admin pages” and require a minumum permission level of 10 (see /pages/admin/analytics.tsx for example)
      • Other pages are open to any viewer (see /pages/home.tsx for example)
    • If we have a viewer with insufficient permissions, they are redirected to the home page
    • If we do not have a viewer, the client is redirected to the sign in page
  • Roles
    • Normal viewer and admin viewer
    • Admin determined by a permissions threshhold provided by server-side context

Adding webnative

  • Should webnative live alongside the current auth system?
    • This could be difficult because the server would need to know about webnative auth status
  • Are there currently limits on storage deals?
    • If so, how is storage deal usage tracked?
  • Can users use their own FIL wallets or is it all DataCap for now?
  • Implement webnative auth with a custom hook or context provider?
  • How do we handle roles and admin-only pages?
2

Yes. I propose that we literally add web auth as another flow inside of the existing app. This may mean replacing the current password based systems, but the goal here is to see how it works.

We will send FIL from user wallet to Estuary wallet, so that may be the point of “backend” integration – basically use the FIL public key on the server side for tracking.

There is likely some overlap here with Cosigner too.

I would say admin pages are out of scope for now. This is for “end user” end to end FIL interactions.

3

@bgins and I were actually just on a call talking through this. In terms of Fission auth in estuary-www. Here is my proposed flow:

  • Add a “sign in/up with Fission” button to the appropriate pages in estuary-www
  • When the user returns from the auth-lobby, we check if their WNFS file system has an estuary API key
    • If yes, then proceed to load/set that API key and proceed as normal
    • If no, then we show an interstitial page prompting them for their invite code (Optionally: Show username - prefilled with fission username, allow them to set their password?) then submit it as a registration, receive the API key and set it in the user’s WNFS.
  • Once the API key is set, proceed to the rest of the frontend per usual.
1 Like
4

That works!

And then the only other new flow is showing how much FIL a deal will cost and getting FIL from the user.

5

Right, that will need some modifications on the estuary backend to have some level of understanding around a user having their own FIL.

6

I’ve implemented our proposed plan to add Fission auth to the existing estuary-www authentication system. Here is a summary outline of how it works:

Sign Up

  • User does not have a Fission account
    • Redirect to Fission Auth Lobby where they grant permission to use their storage and the fil-cosigner key
    • Redirect back to a new interstitial “Account Setup” page
    • User signs up as usual with username, password, and invite code (maybe we can not require a password here?)
    • Two tokens are requested
      • One that is set as a cookie in the usual way
      • A second one is stored in WNFS for the next time the user signs in. This token is stored encrypted at rest.
      • We do this because the first token will be invalidated when the user signs out
    • Redirect to the user’s home page
  • User has an Estuary account and is signed in with Fission
    • Read the token from WNFS and set it as a cookie to authenticate the user
    • Request a second token for next time and replace the stored token with it
    • Redirect to the user’s home page
  • User has an Estuary account and is not signed into Fission
    • Redirect to Fission Auth Lobby where they grant permission to use their storage and the fil-cosigner key
    • Redirect back to the new interstitial “Account Setup” page
      • Look for the user’s stored token. They have one, so redirect to a new “Authed with Fission” interstitial page
      • This second redirect isn’t ideal, but we can’t know if the user had a stored token before we authenticate them
    • User clicks a “Contiue to Estuary” button
      • Another token is requested and swapped out as above
    • Redirect to the user’s home page

Sign In

  • User has an Estuary account and is signed in with Fission
    • Read the token from WNFS and set it as a cookie to authenticate the user
    • Request a second token for next time and replace the stored token with it
    • Redirect to the user’s home page
  • User has an Estuary account and is not signed into Fission
    • Redirect to Fission Auth Lobby where they grant permission to use their storage and the fil-cosigner key
    • Redirect back to the new interstitial “Authed with Fission” page
    • User clicks a “Contiue to Estuary” button
      • Another token is requested and swapped out as above
    • Redirect to the user’s home page

In cases where a user attempts sign in without a stored token they are shown an alert with an error message.

1 Like