Allow separate access/refresh transport

[Maciej Kozik]

Problem
Currently there the API doesn't support different access and refresh tokens transports (for example one should be stored in a HTTP only cookie, while the other in header).

Motivation
If separate transports were possible, one could store refresh token in a HTTP only cookie, and access token in headers (which would later be saved by the client in localstorage). This approach could yield better security if both tokens were required to generate a new access token:

• A rouge JS script / XSS attack could only steal access token and use it until it's expiry
• CSRF wouldn't be an issue when access token was stored in localStorage and both refresh and access (possibly expired, but with valid signature) tokens were required to generate a new access token*
• If refresh token was to be somehow stolen (via man in the middle attack without HTTPS), an attacker would still need to obtain matching access token.*

*- This would require embedding refresh token selector in JWT to figure out if the two match.

Current workarounds
This can be somewhat mitigated when reading by composing requiredSession(oneOff, usingHeaders) { _ => requiredSession(refreshable, usingCookies) { ..., however this will result in the latter directive never finding our access token, and generating a new one.

For writing with setSession (upon user login with basic credentials), one could work around this by composing setSession calls, and manually removing excess cookies/headers.