handle the last leg of oAuth

[maxgrossman]

#52 still has one more leg of work left.

I had not really thought about what we do when the callback URL is successful.
We cannot do what we do now (just return a JWT).

Since the request made to the callback endpoint is a popup window separate from the SPA app that really needs the JWT, we'll need to add "one last leg" to get the JWT to our front end SPA.

To do this, we need the callback URL to return a 302/307 http response with 2 characteristics

1. the location header set to ${maprules.base}/authorized?user=${user.that.was.logging.in}
2. an httponly session cookie that maps to one of the login sessions we keep track of in the sessionManager class.

To encrypt this cookie, maybe we just send it through the jwt sign function??

Then, when the front end loads its location to that new path /authorized it will try to make a req to something like /auth/token which will reconcile if http session cookie (which it sends) and the user in the query parameter to a current session in the SessionManager. If it successfully finds one, we reply to the JWT that the app can use for user-protected routes

This def feels convoluted, but the initial decision to use JWT (which has a convention of being sent in an auth header, not some httponly session cookie) leaves us here, needing a final step.

This also implies getting away from yar. I guess I never read docs correctly, but the yar object is handler request specific, it is not some global to server object that you can look up things with. I think if we encrypt session cookies the front end receives we are left at a similar place I was trying to get with yar - don't just make the all the session details readable without some sort of key.