Add Schema Directives, NextJS, and token refetching about prisma-auth0-example HOT 10 OPEN

@alexbudure

I have an Auth service set as React Context. Within that service, I have a "renewToken" method.

 renewToken = () => {
    return new Promise((resolve, reject) => {
      if (!this.lock) this.loadLock()
      if (!this.state.authenticating) {
        this.setState({ authenticating: true })
        this.lock.checkSession({}, (err, authResult) => {
          this.setState({ authenticating: false })
          if (err) {
            console.log("renew token error", err)
            reject(err)
          }
          console.log("auth result", authResult)
           // this is a mutation to apollo-link-state where the tokens are saved in local storage.  TODO: move to cookies

  
            this.props.client.mutate({
              mutation: REFRESH_ACCESS_TOKEN,
              variables: { accessToken: authResult.accessToken }
            }).then(resolve)
          
        })
      } else {
        resolve()
      }
    })
  }

Then as an Apollo Link...

  import { setContext } from "apollo-link-context"
  const renewAuth0Token = setContext((request, { renewToken }) => {
    // TODO:  logout when idToken is invalid
    if (
      !isValidToken(getAccessToken()) &&
      isValidToken(getIdToken()) &&
      renewToken
    ) {
      return renewToken()
    }
    return null
  })

How does renewToken get in there?

const User = ({ children }) => (
  <AuthContext.Consumer>
    {({ renewToken }) => {
      return (
        <QueryWithLoading
          context={{ renewToken }}
          dataPath="me"
          query={USER}
          ssr={false}
        >
          {(data, allMethods) => {
            return children(data, allMethods)
          }}
        </QueryWithLoading>
      )
    }}
  </AuthContext.Consumer>
)

I'll be putting renewToken into QueryWithLoading directly soon. QueryWithLoading just wraps Query to handle loading states.

Did that help?

from prisma-auth0-example.

I have started working on the NextJS integration. Check out the next-js branch for progress! I hope to have it running next week.

from prisma-auth0-example.

Hey @agustif ,

Sorry for the delay. I'm hard at work with that pesky make a living crap. 😄

As mentioned on Twitter, with the exception of schema directives, I have the above stack working on my own app. If you're stuck or have questions before I update this boilerplate, please let me know. I'm happy to share the files and ideas.

from prisma-auth0-example.

@LawJolla THANKS I didn't answer before because I'm still looking for an a apartment to stay in Paris before ecole 42, starts, but this is just perfect for me now to ship my MVP for our backend tools

from prisma-auth0-example.

As I said on twitter, eagerly waiting for those updates to use them in my own projects! It gets kinda hard getting it all working client+Server

from prisma-auth0-example.

Hey @LawJolla

Can you please share how you implemented token refetching? 😄

from prisma-auth0-example.

@LawJolla I was just wondering your thoughts on the graphql side implementation of the refresh token. I was thinking about doing it a similar way you did but I'm concerned anyone with an access token can just refresh it.

from prisma-auth0-example.

Hey @ryankauk !

Can you explain your concern a bit more?

An access token cannot refresh itself -- that's the identity token. The idea is the identity token is long lived but the access token is short. If the permissions or authorization change, that'll be reflected in the next access token refresh.

from prisma-auth0-example.

Yea for sure, I saw this part ...
this.props.client.mutate({
mutation: REFRESH_ACCESS_TOKEN,
variables: { accessToken: authResult.accessToken }
}).then(resolve)

which I would assume the client side would give the graphql server the access token, and the server would have the client id, client secret and refresh token from auth0 and would take the access token, probably do some validation of it and then the server would give the refresh token to auth0 and return back the access token to the front end.

from prisma-auth0-example.

@ryankauk Sorry for the delay!

It actually works a little more third party than that. Your server doesn't communicate with Auth0 in the token process. The flow should be...

Client Login -> Auth0 -> ID_Token & Access_Token Generated -> Client -> Server -> Server validation

The client also has the responsibility to refresh the access token. That can happen in a few ways, but generally.

Client Request -> Client middleware sees access token expired -> pauses request -> sends ID token to Auth0 -> Auth0 returns new access token -> client resumes request with the new access token.

You server's only job is to validate that the token is signed with the right key and not expired.

from prisma-auth0-example.