| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 0582565fa7db4b95e86fb0dde8d83e3170e566a7.
Adding the user roles to the token makes the token ridiculously
large. Rather than doing that, we'll use an endpoint on the auth
server to get the user roles and privileges instead.
|
|
|
|
|
|
These linting errors can't be rebased into the newer commits.
|
|
|
|
Have each JWT token have a `jti` claim (JWT ID) to help with tracking
refreshes, and therefore validity of the JWTs.
If a refresh token is used more than once, then that refresh token,
and all its progeny/descendants are considered invalid, since that
token could have been stolen.
|
|
This shim enables us to have a refresh token with the JWT. This might
not be the way to refresh JWTs - this is because the
`authlib.oauth2.rfc7523.token.JWTBearerTokenGenerator.__call__(…)`
method has a comment that states:
# there is absolutely no refresh token in JWT format
Searching on the internet, however, seems to indicate that JWTs can be
used in conjunction with refresh tokens... We need to verify this and
fix this if necessary.
|
|
|
|
|
|
Authenticate with the usual authentication code flow.
Do not inherit AuthenticationCodeGrant in JWTBearerGrant, instead, use
the JWTBearerGrant to generate the token after the user has already
been successfully authenticated.
|
|
|
|
|
