Graphql-engine: JWT token expiration

[pyankoff]

I'm getting this error after Firebase JWT token expires (1 hour):

{"graphQLErrors":[],"networkError":{"response":{},"statusCode":400,"result":{"errors":[{"path":"$","error":"Could not verify JWT: JWTExpired","code":"invalid-jwt"}]}},"message":"Network error: Response not successful: Received status code 400"}

Docs mention that graphql-engine will refresh the JWKs automatically. Is there some setting I'm missing?

[coco98]

Are you sure it’s not your client side token that’s expired? Hasura will
automatically refresh the keys, but the tokens have to refreshed between
the client and firebase.

On Mon, 19 Nov 2018 at 8:36 AM, Andrey Pyankov [e-mail]
wrote:

I'm getting this error after Firebase JWT token expires (1 hour):

{"graphQLErrors":[],"networkError":{"response":{},"statusCode":400,"result":{"errors":[{"path":"$","error":"Could
not verify JWT: JWTExpired","code":"invalid-jwt"}]}},"message":"Network
error: Response not successful: Received status code 400"}

Docs mention that graphql-engine will refresh the JWKs automatically
https://docs.hasura.io/1.0/graphql/manual/auth/jwt.html. Is there some
setting I'm missing?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hasura/graphql-engine/issues/1062, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIAWFQ1nnnRrNPjs5UV6w2_6Nv4_5Obks5uwt4JgaJpZM4YpeT_
.

[pyankoff]

@coco98 thanks for reply. Yeah, that's client side token, my bad.
Closing the issue.

[dimofte]

@pyankoff I'm facing a similar issue, a subscription is triggering this error after the 1h.
Were you using firebase auth, by any chance? If so, how did you solve this issue?

[pyankoff]

Yeah, using firebase. I'm getting the firebase token on every request: const token = await user.getIdToken().
Not sure it will fix the 1h problem, but here is my code using Apollo:

const wsLink = new WebSocketLink({
  uri: WS_URL,
  options: {
    lazy: true,
    reconnect: true,
    connectionParams: async () => {
      const token = await user.getIdToken();
      return {
        headers: {
          Authorization: token ? `Bearer ${token}` : "",
        },
      }
    },
  },
})

[dimofte]

I see, many thanks for the answer!
To me, this looks like the token is produced just before the first WebSocket message is sent, when setting up the subscription, so if the subscription lasts longer than 1h, it will also expire.

Perhaps I'm missing something, like the actual meaning of lazy and reconnect (although my app behaves the same with both set to true. I can't find docs on the topic). So this code works for you for long-running subscriptions?

[pyankoff]

I don't know, haven't tested long running subscriptions.

[ecthiender]

@dimofte The general pattern to refresh a token was discussed here: https://github.com/hasura/graphql-engine/issues/2275#issuecomment-496219942

The pattern should apply for Firebase as well. Firebase SDK should also have similar methods to refresh the token.

[dimofte]

Thanks for the link, it's useful, referring to a piece of code which confirms a strategy that I've already tried. It didn't fully work for my setup (react-native with an iOS simulator), but it's very possible to have happened just because of the testing conditions. I will try out this thing soon in a built android app

[dimofte]

@pyankoff I solved the problem, it was caused by a silly thing: I had a test console.error left in case of subscription error. In react-native development mode, this becomes a fatal error, and it was thrown before the SDK refreshed the tokens. W/o this, the SDK keeps the tokens up to date.
Which means your code also works for long-running subscriptions. But, on a side note, I think a better approach is to set the connectionParams on the WebSocketLink, to avoid fetching a new token for each new request
Thanks for the help!

[wollerman]

@pyankoff and @dimofte

To me, this looks like the token is produced just before the first WebSocket message is sent, when setting up the subscription

This is exactly what happens. We have users that stay on a page for longer than an hour and the token expires. So this actually ends up never using the refresh functionality.

Specifically for apollo it seems like the way to handle this isn't 100% ironed out. But I did find an option that I'm going to try out: https://github.com/apollographql/apollo-link/issues/197#issuecomment-504604789

[beaussan]

@wollerman I am still having this issue, did you find a proper solution ?

[wollerman]

@beaussan I ended up implementing something to do refresh on the client side. Check out the link in my earlier comment. I also might be able to dig up the exact snippet.

[wollerman]

@beaussan here's a gist of how we dealt with this at the time: https://gist.github.com/wollerman/1226d2cff7adbee7ff19e22a523e53f9