Postgraphile: Multiple JWT secrets to support rolling change

[pvdvreede]

Hi there,

I really like your PG JWT spec and think its a good idea to standardise so that people can use both postgrest and/or postgraphql.

Just wondering what your thoughts are around allowing people to put two secrets eg a comma separated list for the --secret parameter when starting postgraphql. Both of these would be valid and perhaps it would try the first one and fallback to the second one.

The reason for this is to support the ability to do a rolling change of your JWT secret across your services without having to deploy them at EXACTLY the same time.

For example if you have a user service separate from Postgraphql that generates the tokens, and you want to use them with postgraphql, both services need to have the same secret. When you need to change the secret because of a compromise or general security policy to rotate secrets it would be heaps easier to allow postgraphql to accept the old one AND the new one for a while until all services have been swapped to the new secret and the old JWTs have expired. Then you can remove the old secret from all services and only have the new one.

Does that sound like a reasonable request, or is there another way to handle a JWT secret change? Or perhaps I am totally misunderstanding how the secret works... 😕

[pvdvreede]

The other thing that would be nice to have is the ability to set what the aud claim should be on the command line. This would be great so that you could use services like auth0 etc as the authentication system that generates the jwt. For example their JWTs would have your client id as the aud: https://auth0.com/docs/jwt

[calebmer]

Yeah, this does seem like a reasonable request. One thing I instantly think about is if you're secret is compromised is it really worth still accepting it? Even so the option to do a rolling change would be nice.

Also, how do you feel about removing aud support entirely? It seems to me like checking these properties could be easily set in a piece of middleware so it might not be worth adding a bunch of flags in PostGraphQL.

[burkhardr]

I feel like the entire jwt auth could just be middleware, e.g. this is how I'd done it in koa:

export function checkAuthentication({ debug }) {
  return async (ctx, next) => {
    // get token from headers (or cookie in dev)
    const token = ctx.request.headers.authorization || (debug && ctx.cookies.get('Authorization'));
    ctx.assert(token, 401, 'No token supplied');

    let data;
    try {
      data = jwt.verify(token, sessionSecret);
    } catch (err) {
      ctx.throw(401, 'Incorrect token');
    }

    ctx.jwt = data;

    await next();
  };
}

export default function setupTransaction() {
  return async (ctx, next) => {
    const { pgClient, jwt } = ctx;
    const { role, tenantId } = jwt;

    // start transaction
    await pgClient.queryAsync('begin');
    await pgClient.queryAsync(`select set_config('role', '${role}', true)`);
    await pgClient.queryAsync(`select set_config('jwt.claims.tenant_id', '${tenantId}', true)`);

    await next();

    // commit transaction or rollback
    await pgClient.queryAsync('commit');
    pgClient.end();
  };
}

[pvdvreede]

@calebmer good point about a compromised secret - it would be better to have downtime than allow that. I suppose this use case is more for standard secret rotation as a security policy than for when a secret is compromised.

I would be happy to have this stuff as a middleware so that I can customise the secret rotation and specific jwt claims as required. Does this mean we would need the library setup in #48?

[calebmer]

Ah, wish you had left a comment on #48, just merged it 😊

Anyway, yeah making this customizable in some way does seem like a good idea. What you could do now is keep a secret that only an authentication middleware and PostGraphQL knows about and rotate a public facing secret in a middleware. So something like this process:

1. Request comes in with a token.
2. Your authentication middleware uses a rotating secret to verify the token.
3. Your authentication middleware signs the token with the shared secret with PostGraphQL.
4. Set the newly signed token to the Authorization header so PostGraphQL can use it.

Yeah it’s not ideal, but it could work and could be secure 😉

[sheerun]

Global secret seems really unsecure for me. I'd prefer per-user secrets with rolling change support.

The easiest way to implement it is via middleware like you mentioned

[calebmer]

If anyone with more expertise then me wants to submit a PR for any of these methods, I’d happily merge it 👍

[slaskis]

I'd love to see support for this using an environment variable such as SECURE_KEYS.

This way when hosting on a service like Heroku we could have rolling secure secrets up and running by just enabling this addon: https://devcenter.heroku.com/articles/securekey#provisioning-the-add-on

[benjie]

I think this should be pretty easy to implement; so a PR would be welcome. You can also implement this yourself using pgSettings and bypassing the built in JWT support.