Refreshes are activity-based and synchronous-on-expiry, so the proactive
leeway only hides refresh latency and provides retry headroom; it is not
what prevents serving expired tokens. Shrink it from 5m to 30s to align
with identity provider guidance against refreshing long before expiry,
while keeping decent end-user UX.
This drops the calling function, filepath and line number attributes
for redisotel tracing. The underlying implementation here calls
runtime.Callers, which are more expensive than we'd like.
The default auto-refresh behaviour occurs 5 minutes before tokens
expire, at the earliest. Without inactivity however, tokens are still
refreshed at any point after this, as long as the session has not ended.
This however, means that refreshes don't occur often enough when inactivity
timeouts are enabled. In practice, the session is only refreshed if a
request is received within the 5 minute leeway window between a token's expiry
and the inactivity timeout.
This commit will apply auto-refreshes at the half-life of the inactivity
timeout instead, so that users' sessions and timeouts are properly
extended on activity.
These feature flags were enabled by default. We specifically disallowed
the use of automatic refresh with the SSO mode, though this poses some
complexity if using the forward-auth feature.
To simplify configuration and code, we remove the flags in their
entirety as session refresh behaviour is mostly already handled by the
implementation of GetSession() in the handlers. Specifically:
- the Standalone handler needs to refresh sessions when reverse-proxying
to the upstream.
- the SSO server handler needs to refresh sessions only when using the
forward-auth feature. It does not have an upstream to reverse proxy
to.
- the SSO proxy handler is a read-only upstream proxy and does not
possess the ability to refresh sessions itself, though it will
delegate traffic for the session endpoints to the configured SSO server.
Automatic refreshing is thus only disabled when running in SSO mode
without the forward-auth feature.
The use of these headers in upstreams may be risky, espeically
if Wonderwall is accidentally misconfigured or disabled, or requests
are performed directly to the upstream circumventing Wonderwall.
We should prefer using a signed token or similar that can be verified by
the upstreams.
- stop using jti, use sid instead
- store amr and auth_time from id_token in session
- log more metadata on login callback
- log session id where possible
- propagate acr, amr, auth_time, sid to upstreams in headers
- log authenticated reverseproxy requests
We use the context from the inbound http.Request, which means that this
error generally occurs due to the user agent disconnecting mid-request.
Skip logging these errors as they're not really actionable.
Replace the usage of a single application-wide session crypter
with per-session crypters.
The application is no longer able to decrypt any session
encrypted with its symmetric key alone. Instead, a session ticket
with its associated data encryption key (DEK) is also required in order
to decrypt the associated session data. The ticket itself is
encrypted with the application's crypter; the latter of which is
effectively a key-encryption key (KEK).
Fixes#49.
Trong Huu Nguyen
J-K. Solbakken