Postgraphile: Set the expiry date for the jwt token

Created on 4 Dec 2016 · 10Comments · Source: graphile/postgraphile

Hi folks!

This project is simply stunning 🎉. Now I am learning how to use it and use it to build applications.

I had a few questions, the answers I could not find in the documentation, and I would be very happy if you helped me to deal with them 🙂

Documents paid little attention to the entire authorization process.

The JWT token has exp field to set for 1 day, what would happend after the expired date? I expect that the token will not be accepted by database, but I couldn't find information about this in the documentation.
Is it possible to change the ttl of the token? I think it would be nice to set the ttl of the token via the key.
If I want to use another authorization system through JWT which fields I need to use the database accept it?

{
  "role": "forum_example_person",
  "person_id": 1,
  "iat": 1480784217,
  "exp": 1480870617,
  "aud": "postgraphql",
  "iss": "postgraphql"
}

This fields is forum_example JWT key fields. Which fields check for work with postgres?
role, person_id, exp and aud?

It will be great if you add some examples of work refresh with tokens 😳

Thank you so much for this project, it is very much easier in many aspects of building a full stack applications 🏄🏼

Source

dex157

Most helpful comment

Thank you so much for your this issue, it’s very helpful to know where the documentation can be improved :wink:

I’ll try to write an article on this sometime soon including a refresh token example. As for now here’s some answers:

You got it, the token will be rejected effectively logging the user out requiring them to reauth for a new token.
If you add an exp attribute to your JWT type, you can override the expiration time. exp should be an integer representing the seconds since the Unix epoch. In projects I’ve worked on before, you could express that integer with some SQL like this extract(epoch from (now() + interval '1 week')). That should give your token a one week expiration. Your type definition would look like so:

create type forum_example.jwt_token as (
  role text,
  person_id integer,
  exp integer
);

The minimum viable JWT you would need to create must have an aud set to postgraphql. So { "aud": "postgraphql" }. The rest is completely up to you. exp sets the expiration time, role is the database role, there are some other reserved claim names, and anything else is simply passed on to the database.
I’ll try to do this soonish, however it isn’t too hard to implement on your own :+1:

calebmer on 6 Dec 2016

👍6

All 10 comments

The PG JWT spec may answer a few of your questions here, particularly number 3.

benjie on 4 Dec 2016

Thank you so much for your this issue, it’s very helpful to know where the documentation can be improved :wink:

I’ll try to write an article on this sometime soon including a refresh token example. As for now here’s some answers:

You got it, the token will be rejected effectively logging the user out requiring them to reauth for a new token.
If you add an exp attribute to your JWT type, you can override the expiration time. exp should be an integer representing the seconds since the Unix epoch. In projects I’ve worked on before, you could express that integer with some SQL like this extract(epoch from (now() + interval '1 week')). That should give your token a one week expiration. Your type definition would look like so:

create type forum_example.jwt_token as (
  role text,
  person_id integer,
  exp integer
);

The minimum viable JWT you would need to create must have an aud set to postgraphql. So { "aud": "postgraphql" }. The rest is completely up to you. exp sets the expiration time, role is the database role, there are some other reserved claim names, and anything else is simply passed on to the database.
I’ll try to do this soonish, however it isn’t too hard to implement on your own :+1:

calebmer on 6 Dec 2016

👍6

@calebmer, @benjie thank you for your answers, it's very helpful 😎

dex157 on 6 Dec 2016

Is there a refresh token example available yet?

chris-guidry on 5 Jun 2017

Not AFAIK

benjie on 6 Jun 2017

I'm trying to conceptualize how the refresh should work. Is this the correct approach?

I currently have an authentication/authorization component that wraps all routes that require authorization and verifies the JWT against the database using the current_person function as described in the Authentication and Authorization documentation.

Should I add a mutation to that wrapper component that will generate a new JWT token based on: current_setting('jwt.claims.person_id')?

The JWT expiration is set to one week so would it be sufficient to just run this additional mutation once/day?

chris-guidry on 12 Jun 2017

@chris-guidry if I understand the concept correctly, reset tokens are sent to the user when they login. Successive requests only include the JWT. If the user sends along the reset token, they can get a new JWT. It shouldn't be based on the current user, at that would allow anyone with a valid JWT to get another valid JWT which isn't really the point. If a JWT expires, it will no longer be valid, at which point the user would send along the reset token and a new JWT would be dispatched assuming the reset token is valid.

chadfurman on 22 Jun 2017

How is everyone doing the refresh token nowadays?

Btw, a quick googling net me one possible solution using react apollo and apollo client:
https://github.com/apollographql/apollo-client/issues/1784

pencilcheck on 24 Nov 2017

Any word on refresh token strategies with the github sign in example?
Do you think that forcing the user to sign in again once the JWT has expired is a better option than allowing them to refresh once the JWT is expired?