Redis optional + JWT validation

This release supercedes 1.3.0 which will be deleted

This release introduces a breaking changes to validateHTTPBearerToken and validateToken, please read to determine if this affects you!

Summary

The Persona server now issues JWTs and prior to this release, the client has been treating them opaquely. This release enables the client to inspect these tokens to perform self-validation.

This release also eliminates the dependency on Redis by introducing a cache abstraction layer (via cache-service). The old configuration (as passed when initializing a new Persona Client) is deprecated, but will automatically set up a cache-service-redis based cache, with a warning. By default, Persona Client will use an in-memory cache (via node-cache).

Changes

When using validateToken or validateHTTPBearerToken functions, token validation is now performed by the client rather than calling Persona. The exception to this rule is when there are too many scopes to put into the token payload. When this is the case, the client validates against the Persona server as it did before this release.

By default, Persona client no longer uses Redis, but it's still supported (as well as any other cache supported by cache-service modules. See the README for cache configuration options.

Deprecations

• validateToken: The overridingScope parameter is no longer used and will throw an exception if it is passed. The only use case for this parameter is to ask the client to validate a token using su scope if the provided scope parameter fails validation. This is now done automatically.
• validateHTTPBearerToken: The scope parameter is no longer used and will throw an exception if it is passed. The only use case for this parameter is to ask the client to validate a token using su scope if the a scope provided within the request object fails validation. This is now done automatically. Users of this function should continue to just pass (optionally) a scope they wish to validate against as a request parameter, e.q. req.params.scope

Check and return insufficient scope when validating token

This is a breaking change.

When calling validateToken, you can now get back an INSUFFICIENT_SCOPE error when applicable. This is to allow detection of tokens where the scope is insufficient for the task being performed. Originally, you would just get back a VALIDATION_FAILURE message irrespective of the reason.

New methods for getting, adding or removing user scopes

Non-breaking change:- created new methods for getting user scopes, or adding a new scope or removing an existing scope

Removed exception case to conform with the norm

Merge pull request #8 from talis/fix-error-handling

Remove throwing of exception

Added methods for getting and updating a user profile

Merge pull request #7 from talis/add-profile-functionality

90% Added functionality to get and update a user profile

Evolution from Middleware

!! BREAKING API CHANGE !!

The method validateToken is now called validateHTTPBearerToken. The validateToken method validates a token against Persona, while the validateHTTPBearerToken method validates a token that originates from a http call (one of the attributes required is a http request object).

Authorizations support

• Allows creation and deletion of client authorizations
• Fixed token with scope validation

Cache token issue

• generateToken -> obtainToken
• ... and will cache on repeated call until expiry minus one min

Generate tokens as well as validate them

Allows you to generate tokens if you have a client id and secret pair

Better Logging

Added more logging to the isPresignedUrlValid() method.