[DEPR]: EDX_API_KEY

Proposal Date

2024-01-10

Target Ticket Acceptance Date

2024-01-24

Earliest Open edX Named Release Without This Functionality

Redwood - 2024-04

Rationale

Historical context:

• In 2016-Oct, some security concerns were noted about this key. Specifically, that this symmetric shared secret, which is a pattern we wish to move away from. Related, it is difficult to rotate.
• Class ApiKeyHeaderPermission was marked deprecated in 2020-Feb.
  • This was done as part of a larger PR, and doesn't have any useful comments.
  • It does add some observability for usage.
• The ticket https://openedx.atlassian.net/browse/ARCHBOM-1077 from 2022-Mar was to "Deprecate and remove ApiKeyHeaderPermission". This was closed without finishing simply due to it not bubbling up in priority.
  • This decision does not seem to be mentioned outside of these tickets, which were meant to document this.
  • As of March, 5, 2026 - 2U only saw to calls in the past 2 weeks (the length of time for which we have data) we only saw two uses with the custom attribute deprecated_api_key_header. Both were calls of the form: https://courses.edx.org/api/enrollment/v1/enrollment?user=xxxxx

Removal

To be removed:

• Here is a Github search for the following:
  • ApiKeyHeaderPermission (and all uses)
    • This is marked as "deprecated" in the docstring, but with no comments nor a link to this ticket as of 2024-Jan.
  • Other shared classes using this permission class:
    • ApiKeyHeaderPermissionIsAuthenticated (and all uses)
    • ApiKeyPermissionMixIn
    • Note: These have not been marked deprecated as of 2024-Jan.

Replacement

From ARCHBOM-1077:

The preferred way of granting this type of permission is by using the OAuth2 client credentials grant <https://tools.ietf.org/html/rfc6749#section-4.4>__. The ecommerce-worker would be granted the permissions of a user allowed to enroll any other user in any course.

The newer OEP-66: User Authorization could also be referenced.

Deprecation

No plans, but we could add additional comments to the shared classes.

Migration

TBD

Additional Info

Additional notes from the closed/unfinished ticket (ARCHBOM-1077):

• In one particular case, the ecommerce-worker application needs the permissions to be able to enroll any user in any course and to modify course pricing metadata by hitting both the "enrollment" and "commerce" LMS APIs. This privileged permission is granted via an API key header, where the API key is essentially a shared secret between the LMS and the worker. The permission is granted outside the context of any particular user.
• The forums IDA <https://github.com/edx/cs_comments_service>__ also use the API key header. The actual header name is: X-Edx-Api-Key.

Task List

• Announce and put for RFC
• Mark as deprecated for next release
• After the next release happens, remove the above classes and any other code that uses the EDX_API_KEY.
• Ensure it gets into the next release notes.

(There may be other steps needed for the DEPR process. This is just a broad outline.)

Start by reading openedx/core/lib/api/permissions.py and searching the repository for ApiKeyHeaderPermission, ApiKeyHeaderPermissionIsAuthenticated, ApiKeyPermissionMixIn, and EDX_API_KEY. Review the listed uses, including openedx/core/djangoapps/enrollments/views.py, and confirm the migration and release-note requirements before defining completion.