# Questions

1. Should we use refresh tokens?

Maybe.  The signal server should periodically check back with the server to see if the current token is still active (that is: has the user logged out or made substantial changes?)

References:

1. https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them//
2. https://stackoverflow.com/questions/11357176/do-oauth2-access-tokens-for-a-mobile-app-have-to-expire
3. https://stormpath.com/blog/manage-authentication-lifecycle-mobile
4. https://stackoverflow.com/questions/48644759/how-a-mobile-app-will-refresh-access-token-without-refresh-token-implicit-gran
5. https://gist.github.com/ziluvatar/a3feb505c4c0ec37059054537b38fc48

There is an example of a JWT refreshing here

```
/**
 * Example to refresh tokens using https://github.com/auth0/node-jsonwebtoken
 * It was requested to be introduced at as part of the jsonwebtoken library,
 * since we feel it does not add too much value but it will add code to mantain
 * we won't include it.
 *
 * I create this gist just to help those who want to auto-refresh JWTs.
 */

const jwt = require('jsonwebtoken');

function TokenGenerator (secretOrPrivateKey, secretOrPublicKey, options) {
  this.secretOrPrivateKey = secretOrPrivateKey;
  this.secretOrPublicKey = secretOrPublicKey;
  this.options = options; //algorithm + keyid + noTimestamp + expiresIn + notBefore
}

TokenGenerator.prototype.sign = function(payload, signOptions) {
  const jwtSignOptions = Object.assign({}, signOptions, this.options);
  return jwt.sign(payload, this.secretOrPrivateKey, jwtSignOptions);
}

// refreshOptions.verify = options you would use with verify function
// refreshOptions.jwtid = contains the id for the new token
TokenGenerator.prototype.refresh = function(token, refreshOptions) {
  const payload = jwt.verify(token, this.secretOrPublicKey, refreshOptions.verify);
  delete payload.iat;
  delete payload.exp;
  delete payload.nbf;
  delete payload.jti; //We are generating a new token, if you are using jwtid during signing, pass it in refreshOptions
  const jwtSignOptions = Object.assign({ }, this.options, { jwtid: refreshOptions.jwtid });
  // The first signing converted all needed options into claims, they are already in the payload
  return jwt.sign(payload, this.secretOrPrivateKey, jwtSignOptions);
}

module.exports = TokenGenerator;
```
And the tester:
```
/**
 * Just few lines to test the behavior.
 */

const TokenGenerator = require('./token-generator');
const jwt = require('jsonwebtoken');

const tokenGenerator = new TokenGenerator('a', 'a', { algorithm: 'HS256', keyid: '1', noTimestamp: false, expiresIn: '2m', notBefore: '2s' })
token = tokenGenerator.sign({ myclaim: 'something' }, { audience: 'myaud', issuer: 'myissuer', jwtid: '1', subject: 'user' })
setTimeout(function () {
  token2 = tokenGenerator.refresh(token, { verify: { audience: 'myaud', issuer: 'myissuer' }, jwtid: '2' })
  console.log(jwt.decode(token, { complete: true }))
  console.log(jwt.decode(token2, { complete: true }))
}, 3000)
```

2. Is it still safe to store variables in process.env? Can the variables be leaked?

It's probably not possible for the variables to be leaked, although if I was going to attack a node.js process, this is the vector I'd choose.  In any case, for private keys and so forth, better to store as paths that reference files that are not accessible outside the web server.

2. Should I encrypt environment variables and put into source control?

Probably not a good idea, although it reduces the chance of a developer accidentally checking a file in that they were not supposed to.

I'm still not sure if this is a bad idea or not.

This package might help, if I decide to try it out: https://github.com/tkalfigo/dotenvenc


3. What is a node js security checklist?

https://blog.risingstack.com/node-js-security-checklist/


4. How do we use rate-limiting, particularly on the signal server?

Rate limiting is used to control how many requests a given consumer can send to the API.

To tell your API users how many requests they have left, set the following headers:

* `X-Rate-Limit-Limit`, the number of requests allowed in a given time interval
* `X-Rate-Limit-Remaining`, the number of requests remaining in the same interval,
* `X-Rate-Limit-Reset`, the time when the rate limit will be reset.

Most HTTP frameworks support it out of the box (or with plugins). For example, if you are using Koa, there is the koa-ratelimit package.


5. What other configuration packages are out there?

NConf:

https://github.com/indexzero/nconf


# JWT Stuff

## 1. We're going to TEST public/private key pairs for tokens

Benefit:
* Can't recreate a token without the private key!
* Can share the public key around more liberally.

Downsides:
* Order of magnitude slower than symmetric keys.

## 1.a How to manage the key files

General principles:
1. Neither public nor public keys checked into source control.
2. `.env` refers to the key with a path in the local file system.  Loading once at run time (risk of leak?).
3. Public key shared with signal server.

https://security.stackexchange.com/questions/10963/whats-the-common-pragmatic-strategy-for-managing-key-pairs?rq=1


## 2. Generating the keys:

    ssh-keygen -t rsa -b 2048 -f jwt.key

    openssl rsa -in jwt.key -pubout -outform PEM -out jwt.key.pub

Also see: https://gist.github.com/ygotthilf/baa58da5c3dd1f69fae9

## 3. What claims to store against the key?

Reference: https://tools.ietf.org/html/rfc7519#section-4.1

Current list:

* `iss` - the issuer, usually the bigscreenvr domain name.
* `sub` - unused, `locally unique in the context of the issuer`, case sensitive. This is the user id.
* `aud` - unused, `intended recipient of the JWT`. Must be present when the token in processed. Tokens will be shared between signal and accounts server though, so not 100% sure what to put for it.
* `exp` - expiration time, used.
* `nbf` - unused, not before, no need to use.
* `iat` - issued at, a timestamp when the thing was created.
* `jti` - a unique identifier.

Will be storing everything in new JWTs except for nbf.