Auth0 session data translating between apps

Get Help and Help Others
1

I have two different RedwoodJS apps:

A has a frontend and a backend. Uses dbAuth.
B is frontend only, but queries A’s backend via the graphQL API endpoint for some data. Uses auth0.

Previously, B has only queried data that doesn’t @requireAuth, but I’m realizing that I do want to be able to make some queries/mutations that do. I have fairly granular permissions set up in my backend, so I don’t want to bypass the redwoodJS auth altogether. Essentially, I want to be logged into A when I log into B.

What are my options to do this? Some possibilities:

  1. Switch A to auth0. It’s possible that, with the same system of logging in on both, the session data will look identical to the auth setup, so if a user has an account on both, getCurrentUser or isAuthenticated will work on A if tried from a logged in user on B. But I don’t know if this will work, and don’t want to switch login methods for no reason.
  2. Copy A’s backend into B, so it will have all the same logic. This requires a LOT of repeated code, so I would like to avoid this if possible.

If anyone can confirm that 1 works, I’ll happily go with that. With there being two different frontends, setting it up as a monorepo doesn’t feel like a good solution. Other than that, I can’t think of any other ways to do this, but would love to hear suggestions.

2

Hi Zach,

So Option 1 will work, as long as your secrets and keys are the same.

However - if you’d like to continue using dbAuth, have you explored the possibility of setting a different domain on the cookie too? Self-hosted Authentication (dbAuth) | RedwoodJS Docs

I’m imagining that you login in App A, with the domain of B.And you access A’s APIs from B’s FE without issue.

@rob can probably shed more light here!

Thanks,
Danny

3

So I think there are two things needed to get this to work:

  1. Site B needs to be a subdomain of Site A (or vice versa). Setting the Domain of the cookie to example.com will allow it to work on example.com any any of its subdomains
  2. Site B needs to also set the auth-provider=dbAuth and authorization=bearer {userId} headers in every request.

Any idea how to accomplish #2 here @danny? If @Zach installed dbAuth in Site B, even though it’s just the frontend, would Apollo automatically send those up? Although how would it know the userId to set in the authorization header?

It’d be great if everything needed for auth was in the cookie itself, then we wouldn’t need these other arbitrary headers. Maybe in the middleware refactor we can put the auth provider into the cookie itself? Like {provider}|{encryptedCookie}|{encryptionIV}…