[DEPR]: Symmetric JWTs #83
Description
Proposal Date
2022-12-08
Target Ticket Acceptance Date
2022-12-23
Earliest Open edX Named Release Without This Functionality
Quince - 2023-10
Rationale
The decision to deprecate symmetric JWTs in favor of asymmetric JWTs was documented and accepted in this edx-platform ADR in (2018-07-23).
The ADR also details deprecation of JWT_ISSUERS, since the LMS should be the lone issuer of the new asymmetric JWTs.
Since the writing of the ADR, asymmetric JWTs have been used for JWT cookies for MFEs, and many (if not all) IDAs now include this configuration for accepting asymmetric JWTs. The one exception may be ecomworker, which still may be generating its own JWTs? In edx.org PROD, it seems to have its own JWT_ISSUER config, and does not include the JWT_AUTH config included for the other IDAs.
Removal
Before clean-up, we need to switch to create asymmetric JWTs only. We could put this behind a rollout toggle to ensure it is ok. When the toggle is enabled, we could force use_asymmetric_key to be True in this code. This change should be noted for the named release, because all IDAs using JWTs will require JWK config, which must have been added for any IDAs backing an MFE.
Once we are only using asymmetric JWTs, there is a long list of clean-up possible.
edx-drf-extensions jwt_decode_handler:
- symmetric key usage
- get_jwt_issuers usage
- Note: The rollout of changes would need to be very careful. A potential plan was documented in (https://openedx.atlassian.net/browse/ARCHBOM-1161), including confirmation that all services are properly configured to use
JWT_PUBLIC_SIGNING_JWK_SET.
LMS JWT creation:
- symmetric JWT and secret key related arguments
- Note: This would need to happen last, and again would need a careful rollout plan.
Related setting clean-up:
DEFAULT_JWT_ISSUER: Retired?, but the configs were never fully removed. Confirm and delete.JWT_ISSUER: Used by the LMS when encoding JWTs? Should be confirmed and documented, and should not exist in other services.JWT_AUTH['JWT_ISSUER']: This is would be the new "replacement" for the issuer.JWT_ISSUERSlist in case of future changes.)JWT_AUTH['JWT_ISSUERS']: This should be removed from all services except ecommerce (see below).JWT_AUTH['JWT_ISSUERS'][0]entries should exist at top-level ofJWT_AUTH(minus the removedJWT_SECRET_KEY).JWT_AUTH['JWT_SECRET_KEY']: This should be removed from all servicesexcept ecommerce (see below).JWT_AUTH['JWT_ISSUERS'][0]['JWT_SECRET_KEY']: This should be removed from all services.- Note: The contract phase of this clean-up should be possible after each service is only using asymmetric JWTs.
Ecommerce outlier notes:
- Update: It is possible that the DEPR of the old rest client means that ecommerce is no longer creating its own JWTs. That needs to be confirmed. If it isn't, then it doesn't need any exceptional handling.
- The ecommerce service has a custom jwt_decode_handler that uses the
edx-drf-extensionsversion and adds its own support for symmetric JWTs (which it issues). - We must ensure we don't break the ecommerce service, and it should continue to use symmetric JWTs.
- We would have wanted the ecommerce service to also drop support of asymmetric JWTs, but:
- This is lower risk once the other services could no longer accept these symmetric JWTs, and
- Ecommerce is already being deprecated/removed, so no need to put in this extra maintenance work.
Replacement
This will be replaced by the already existing support for asymmetric JWTs.
Deprecation
This was already completed.
Migration
No response
Additional Info
Again, this needs to be undertaken in steps very carefully. There may be additional details documented in the epic ARCHBOM-1202 and its tasks. However, it also assumed that ecommerce would ultimately need to be fixed as well.
For 2U, there are additional configs for JWT_ISSUERS in https://github.com/edx/edx-internal/blob/master/ansible/vars/edx.yml, in addition to remote config.