Multiple JWT secrets to support rolling change about crystal HOT 9 CLOSED

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

from crystal.

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

from crystal.

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.

from crystal.

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();
  };
}

from crystal.

@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?

from crystal.

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 😉

from crystal.

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

from crystal.

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

from crystal.

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.

from crystal.