Load balancers or reverse proxies may rewrite or modify the Location
header and unescape its value, which would result in redirects not
preserving the original set of query parameters. This was especially
evident for autologins where we need to redirect to `/oauth2/login` with
the `redirect` parameter containing the original requested URL so that
the end-user ultimately ends up at the latter URL.
We avoid this issue by base64-encoding the original URL, before passing
it along as the intended redirect for the login route.
To preserve existing behaviour, we use a separate query parameter
for the `/oauth2/login`-endpoint that accepts and handles base64-encoded
values.
A client error response for the refresh grant is assumed to be an
irrecoverable error; e.g. the refresh token is invalid, the
authorization is invalid, user is logged out, etc. In such cases we will
consider the session state to be invalid, and a new authorization grant
should be performed.
One of the changes in OAuth 2.1 addresses attacks with refresh token
replays by recommending the use of one-time use tokens. A refresh token
is thus rotated and invalid after exactly one use, returning a new token
for each successful grant. Any further attempts must thus use the most
recently acquired refresh token. Reusing a refresh token may also
cause the authorization server to invalidate the current active refresh
token, requiring a refresh authorization grant to be reacquired for
further refresh token usage.
The use of locks prevents multiple refresh grant attempts for a given
session from happening across concurrent requests.
Replace hardcoded callback URLs with dynamic generation
of URLs based on incoming requests. These are validated against
a pre-registered list of ingresses for which Wonderwall is considered
authorative for.
We also preserve the cookie behaviour; the most specific ingress path
and domain is used for the cookies.
The `url` package has been moved to the `handler` package, and its
implementation refactored slightly for readability and DRY.