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.
Access Tokens are not necessarily JWTs. We also don't
have to validate them as we only pass it on as an opaque
string.
This also means that we don't log the JTI access tokens
anymore.
We also simplify handling of oidc callbacks.
There's a bunch of changes here, but in essence:
- split out openid configuration
- separate openid configuration between client/rp and provider
- consolidate client and provider related code in separate packages
These changes allow for simplification of the Handler, as well as a
bunch of test/mock code as the configuration is now instantiated
seperately from the client/provider code.
`sid` is a key that refers to the user's unique SSO session at the
Identity Provider, and the same key is present in all tokens
acquired by any Relying Party (such as Wonderwall) during that session.
Thus, we cannot assume that the value of `sid` to uniquely identify the
pair of (user, application session) if using a shared session store.
