Since a part of this ADR details the USE-JWT-COOKIE
header which has been removed, this ADR was updated
with links to the newer ADR.
The status will remain accepted.
A change history was also added for this change,
as well as documenting some past changes.
currently our attempts to clear these tables is cronically failing due
to an unnecessarily huge join for the very first query
I have a suspicion that the performance of this join would improve if
we deleted records from any tables beyond just the first listed here
As part of the implementation of this ADR, we determined that we needed
to make some of the endpoints that return JWTs able to produce
asymmetric JWTs as needed, since asymmetric JWTs are a requirement
in certain cases. This ADR update notes this additional consequence.
The decision to provide Restricted Applications expired
JWTs was superseded by another ADR. This commit simply
adds clarity around that change.
Co-authored-by: Phillip Shiu <pshiu@users.noreply.github.com>
To exchange jwt with session cookies we need to determine JWT grant type in
AccessTokenExchangeView. JWT only having password grant type will be allowed to exchange session.
Added ADR for mobile migration to JWT authentication.
LEARNER-8886
Exchange third party auth token wiith jwt token
since mobile platform is moving to jwt token we
need jwt token instead of access token now.
LEARNER-8517
Co-authored-by: Robert Raposa <rraposa@edx.org>
Moves the functionality from views._get_jwt_dict_from_access_token_dict
to a new method jwt.create_jwt_token_dict, which create a JWT version
of the passed token_dict. Also updates create_jwt_from_token to wrap
this call and return the "access_token" from the dict.
This will hopefully make it less likely that the token
dict attributes could get out of sync with the claims
inside the JWT.
Extract some jwt related methods to enable reuse across views.
This is in preparation for a change to AccessTokenExchangeView.
Co-authored-by: jawad-khan <jawadkhan444@gmail.com>
Introduces JWT_ACCESS_TOKEN_EXPIRE_SECONDS setting. This is the number
of seconds a JWT access token remains valid. We use this custom
setting for JWT formatted access tokens, rather than the
django-oauth-toolkit setting ACCESS_TOKEN_EXPIRE_SECONDS, because the
JWT is non-revocable and we want it to be shorter lived than the
legacy Bearer (opaque) access tokens, and thus to have a smaller
default.
BREAKING CHANGE: The thing that is breaking is that JWT access tokens
will now have a 1 hour default, instead of a 10 hours default. If
third-party scripts are appropriately checking/refreshing the access
token, this should be ok. However, you can always override with a
longer duration temporarily. From a security perspective, we don't
recommend a longer duration, and you may consider a shorter duration.
ARCHBOM-2099
BREAKING CHANGE: Removed unused and misleading custom attributes
used for monitoring:
* `jwt_expires_in`: Removed because it is constant for all requests
and just repeating the setting value. It was also misleading.
* `jwt_is_asymmetric`: Removed because multiple JWTs might be created,
and only the last would be reported, which is misleading. This was
meant to help with a future project to get everyone on to asymmetric
JWTs, but can be added when needed, and probably should ONLY monitor
deprecated (symmetric) usage that needs to be fixed. That can be left
for another day.
