| Age | Commit message (Collapse) | Author |
|---|
|
|
|
We have a similar jwk module in gn2 that does similar functionality.
Moving the newest_jwk_with_rotation function to the module ensures
that there's some consistency between both modules so that when we
ever want to remove the duplication (e.g. by creating some python pip
package) it's easier.
|
|
|
|
|
|
The local sign in request used by gn2 uses json. However, the default
parsing assumes form data, see:
- https://github.com/lepture/authlib/blob/v1.2.0/authlib/integrations/flask_oauth2/authorization_server.py#L72
- https://github.com/lepture/authlib/blob/v1.2.0/authlib/integrations/flask_helpers.py#L5
We create a custom Authorization server that defaults to `use_json=True`
when creating the oauth request object
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With the key rotation in place, eliminate the use of the
SSL_PRIVATE_KEY configuration which pointed to a specific non-changing
JWK.
|
|
|
|
To help with key rotation, we fetch the latest key, creating a new JWK
in any of the following 2 conditions:
* There is no JWK in the first place
* The "newest" key is older than a specified number of days
|
|
The checks for whether a token is already linked, and then revoking it
and raising an error were causing issues in multi-threaded
environments, where there'd be multiple requests to the auth server
all using an expired token.
This just links the refresh token and avoids the check and revocation
for the time being.
|
|
List any/all existing JWKs that the server currently supports.
|
|
Without the `or` later statements were being evaluated, before the
final value was computed. This commit short-circuits that behaviour.
|
|
|
|
|
|
|
|
If a user provides the correct credentials to login, but they are
unverified, redirect them to the email verification page, where they
are provided with a chance to verify their email, or send a new
verification code.
|
|
Creation of a User object from the database resultset will mostly be
the same. This commit moves the repetitive code into a static method
that can be called wherever we need it.
This improves maintainability, since we only ever need to do an update
in one place now.
|
|
|
|
|
|
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.
|
|
|
|
Check whether a refresh token has been used before using it to
generate a new JWT token.
If the refresh token has been used previously, it should be revoked,
and an error raised.
As of this commit the actual revocation process hasn't been implemented.
|
|
|
|
|
|
|
|
These linting errors can't be rebased into the newer commits.
|
|
We need to track the "lineage" of refresh tokens in order to detect
possible stolen tokens and mitigate damage.
|
|
Register the RefreshTokenGrant with the server to enable refreshing of
the tokens.
|
|
|
|
|
|
|
|
Add a model for the JWT refresh tokens.
|
|
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.
|
|
|
|
|
|
Pass in the missing redirect_uri value along with login data. Use the
full URI (complete with request args) as the form's action.
This resolves the error raised when wrong credentials are provided.
|
|
|
|
|
|
|
|
The authorisation server uses its key to sign any token it generates.
It uses the clients' public keys to validate any assertions it
receives from a client using the client's public key.
|
|
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.
|
|
|
|
|
