Authentication Challenges

Some ARCHBOM tickets marked as DONE have an unfinished label because they weren’t actually completed, but just closed. may be useful for anyone working on any of these challenges.

Also see details about the potential funded contribution FC-18 here, labelled as In FC-18 below.

Easier to use

These changes should make authentication easier to use for engineers.

  • In Progress

    • A fresh ticket is probably in order here. I’m not clear on the final proposed solution, and where we need monitoring along the way, but this definitely adds complexity to our authentication, and I think there is a simpler way.

    • (“unfinished”)

      • Not sure if this has any additional useful context, or is redundant and should be forgotten.

  • In FC-18

    • AUTHENTICATION_CLASSES is a default setting for DRF endpoints.

    • This would enable the use of JwtAuthentication from most edx-platform DRF endpoints.

    • DRF endpoints that override the default should be reviewed to see if the override can be deleted, once there is a sane default.

    • Order is an open question: JwtAuthentication before or after SessionAuthentication?

      • Unfortunately, due to differences noted in DEPR(#165), order matters.

      • Also, order matters until ARCHBOM-1218 is implemented.

    • For rollout, propose to add a custom version of BasicAuthentication in edx-platform that adds some monitoring to see how and if it is used in Production.

      • It would be good to drop BasicAuthentication from the defaults if we don’t actually want it.

  • In FC-18

  • In FC-18 (“unfinished”)

    • This may be complicated without further product input, but maybe the solution can be readied regardless.

  • (“unfinished”)

  • Adding an endpoint to LMS to expose the public signing keys. (Unticketed)

    • This would simplify key rotation. It came up at 2U for non-Open edX platform applications that may use the JWT cookie for SSO.

Simpler authentication

These changes should simplify authentication, which may affect engineers in certain cases, but possibly not as directly as the “Easier to use” category.

  • In FC-18

    • New implementation ticket for

    • This would simplify authentication and maintenance, but wouldn’t necessarily add functionality.

  • In FC-18

    • To be considered.

    • Requires working in Prospectus,’s private marketing site, so this is not a good candidate for community work.

  • (“unfinished”)

    • Related? (“unfinished”)



The following tickets may be authorization related, and not really authentication related.

  • (“unfinished”)

    • This is unblocked, because we no longer return expired JWTs for restricted applications.

  • (“unfinished”)

    • Note: The code has since been updated to use, but override, the shared JwtAuthentication class to update global staff role during login.


Changes that might help with observability while monitoring other fixes. These should be kept in mind as we consider other dangerous changes that we with to monitor.

  • (“unfinished”)

    • I have since realized that MonitoringCustomMetricsMiddleware isn’t deployed by enough services, so might be better to just keep calling set_custom_attribute and hopefully the final call wins.

  • (“unfinished”)

  • (“unfinished”)

  • (Unticketed) It would be nice to have a failed_jwt_unauthenticated_user_id to know who may have been trying to authenticate.


  • (“unfinished”)

  • (“unfinished”)

    • It is possible this may pass now that we are using a different library under the covers?


Above tickets were curated from the following: