WIP on Single Sign On

Changes
------------

- [x] Back end support for [JSON Web Token Profile for OAuth 2.0 Client Authentication and Authorization Grants](http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-10)†
- [ ] Front end support for passing a single sign on assertion
- [ ] Switch away from UUIDs for Consumer keys and secrets
  - Keys should be human readable, unique, and different from the Client Id
  - Client Secrets in particular should be longer
  - Both Client Id and Client Secrets should be shared and used for signatures in a URL safe base 64 encoding, for maximum developer convenience, but could be stored in a compact byte representation

† For comparison, consider other Single Sign On systems. Disqus requires an HMAC-SHA1 assertion[[1]](https://help.disqus.com/customer/portal/articles/236206-integrating-single-sign-on) while Discourse requires an HMAC-SHA256 assertion[[2]](https://meta.discourse.org/t/official-single-sign-on-for-discourse/13045). Disqus uses JSON data for the payload while Discourse uses a query parameter string. JWT neatly encapsulates an algorithm header, a payload, and an HMAC signature in a single, url-safe token, and allows the hash and signature algorithm to change over time. The JWT Bearer Token Grant, an OAuth 2 extension motivated by the need for OpenID Connect to decouple the authentication and token endpoints, provides sensible claims with validation criteria. Using JWT also means developers should be able to use existing libraries to easily integrate Single Sign On.