JWT development roadmap & overview

[LukasKalbertodt]

This discussion is for tracking the progress on all things JWT in and around Opencast.
_{OC committers: feel free to edit this post to keep it up to date.}

Please keep discussions here about the general roadmap and plan. For specific technical topics, please open separate discussions.

---

Use cases

We distinguish two main use cases, both involving external apps (LMS, Tobira, ...):

• Static file auth: let external apps use static files of OC (pictures, videos, ...) with proper authorization.
• Tool use-case: let external apps launch Opencast "tools" (Studio, Editor, Player, ...) with the user being properly authorized to use them.

Tasks

• Foundational
  • Initial discussion: How to make external applications (e.g. LMS, Tobira) work with Opencast static file authorization? #5334
  • Standardize JWT schema (what claims to use how) Proposal: standard JWT schema and path for better JWT support #6177
• OC side (receiving & verifying tokens)
  • External file server: octoka https://github.com/opencast/octoka
    • Initial working version
    • Evaluate, community feedback
    • Release v1.0 (production ready) (see Initial development roadmap octoka#2)
    • Bundle/package with Opencast?
  • Opencast
    • First implementation of "Standard Schema" in OC Proposal: standard JWT schema and path for better JWT support #6177
    • Support EdDSA JWT algorithm #6093 -> Replace java-jwt with nimbus-jose-jwt #7052
    • Simplify setting up JWT #7034 -> Vastly simplify JWT setup for common cases #7189
    • Support JWTs for /play in iframe -> Add JWT support to /paella7/ui (with token refresh via iframe host) #7249
    • OC: make it possible to authenticate requests without having a user object Accept JWTs without username for auth #7253
    • OC: figure out session merging. This is required for the tool use case. The question is what happens when two different sessions are started via JWT.
    • OC: support multiple JWKS URLs
• External app side (creating JWTs)
  • Web workers solution
    • The idea is to install a web worker in the frontend, which intercepts all requests to Opencast, automatically inserting a JWT.
    • Initial development
    • Publish code, initial version for testing: https://github.com/opencast/jwtify
    • Evaluate, community feedback
    • Make it production ready
  • Tobira
    • Experimental implementation via web workers
    • Finish implementation
    • Release support as opt-in: Add experimental feature to authorize static files via JWTs elan-ev/tobira#1602
    • Test
    • Enable by default
  • Paella:
    • Gracefully handle 403 when loading static files (asking users to reload in some situations)
    • Consider support JWT via Media Source Extensions: Investigate Media Source Extensions (MSE) for JWT use in Paella #7050 -> not viable
  • LMS
    • Initial implementation in opencast PHP library
    • Proof of concept in a specific LMS
    • Decide how to move forward: player iframe or player as NPM package? -> iframe
      • iframe: test how exactly to make it work with Opencast. JWT can be passed to iframe, but then what? Create cookie-session in iframe? Does that work? Or can the iframe request new JWTs from host page? -> we have a plan; will implement and test it soon.
      • NPM package: would then require built-in support by Paella or service-worker solution.
    • Implement in Stud.IP
    • Release Stud.IP
    • Implement in Moodle
    • Release Moodle
    • Implement in Ilias
    • Release Ilias

Links and resources

• Initial discussion: How to make external applications (e.g. LMS, Tobira) work with Opencast static file authorization? #5334
• Webinar Jul 2025: https://explore.opencast.org/webinars/v/GgLu766Qkvv
• Summit 2025: https://explore.opencast.org/conferences/2025/summit/v/FEEMyoCojlA

[LukasKalbertodt]

Meeting: Paella + JWT?

We just had a meeting about what Paella would need to do in order for Opencast to fully realize the JWT plan.

Short term, we agreed that starting with long-lived JWTs is already a lot better than no static file auth. In that case, we side-step most of the really tricky problems. To nicely support that, Paella should support a way to gracefully deal with 403 errors when requesting static files. Opencast's /play player could for example show a big "Try reloading the page" under certain circumstances. Gracefully reacting to these errors is nice anyway, regardless of our JWT plans. It's still unclear how much Paella already supports and what still needs to be added to its API.

Long term we want to keep JWTs short lived, which is problematic because many HTTP requests don't happen immediately on page loads. Most importantly, videos are not fully downloaded immediately by the browser (in both cases: HLS and progressive download). This means for each HTTP request, we need to generate a new JWT "just in time" and attach it. For things like thumbnails and subtitles, that's easy: they are either downloaded immediately or Paella knows/controls when the request happens. For HLS videos, I would expect hls.js to have a callback that allows you to modify the requests to the individual chunks (does that still work on iOS tho?!). For progressive downloads (i.e. <video src="https://.../foo.mp4">), it's tricky. It's possible via service workers, which can intercept & modify all HTTP requests. But there might be problems using them in LMS plugins (due to how path scoles for service workers work) and there might also be limitations that we don't know about yet (do users disable service workers in their browsers?). With service workers, Paella wouldn't need to change anything. Alternatively, using Media Source Extensions (MSE) might be possible. There is an issue for investigating exactly that: #7050. If that works, Paella could and should have an API to supply a callback that returns fresh JWTs.

We also talked a bit about the "Player in iframe" solution for LMS and how that would work with short-lived JWTs. We didn't conclude anything but we see these three options:

• A long-lived "tool JWT" is passed to the iframe via query URL parameter. The iframe can use that to get JWTs for static file auth via an Opencast API. We need to consider the exact security implications here. If the tool JWT and static file JWTs have the same claims, this is not worth anything. But if the tool JWT lists the user's roles, the OC API generating the static file JWT can still re-perform some checks, meaning that "making a video private" would take immediate effect with that approach. "User is banned from university" is still not addressed as the long-lived tool JWT would still be valid.
• The iframe could get a short-lived JWT and it could regularly get a new JWT from an Opencast API. That would still not address the "close laptop and use it an hour later at university" use case, as the JWTs needs to constantly refreshed. We also need to consider the security implications of this.
• There can be some communication between the iframe and the hosting website (e.g. LMS) so that the iframe can request new JWTs from its host (LMS). Would work with short lived JWTs and with a closed laptop, but makes embedding the iframe harder.

[LukasKalbertodt]

Some quick updates:

• octoka had two new releases, v0.2 and v0.3. The latter one can be seen as release candidate for v1.0 ("ready for production").
• I published jwtify, a library implementing all the service worker logic to automatically attach JWTs to static files. It still lacks documentation and is not yet recommended for production, but I hope that will change soon.
• There is this Tobira PR, which uses jwtify to enable static file auth. That feature is opt-in.
• Arne's PR adding EdDSA support to Opencast has been merged (into develop, i.e. it will be release with OC 19.0)
• I opened a PR to simplify setting up JWT in Opencast

Near term plan regarding octoka, jwtify and Tobira:

• Deploy octoka to several servers to collect experience. If everything goes well, I will release octoka v1.0. Then we can start thinking about packaging it with Opencast.
• Merge & release opt-in static-file-auth feature in Tobira. This will then be tested by various institutions to evaluate it. With that experience, I might still change things about jwtify. If everything goes well, I will write docs for jwtify and then release it in a stable version. At some point, Tobira will enable this feature by default.

[ferishili]

Quick update from the LMS side:

• JWT support is now fully integrated in the Opencast PHP Library and available in v2.0.0.

• The ILIAS Opencast plugin integration is mostly done and currently uses long-lived JWTs. Work is available in this PR: [WIP] JWT Auth integration opencast-ilias/OpenCast#460

  • Now in testing.
  • Still a work in progress because /play compatibility hasn't been added yet.

Next steps:

• We're waiting for /play to support JWTs on the Opencast side. Once that lands, the ILIAS integration will be updated accordingly.
• After that, we expect to tag this as a pre-release and move toward full JWT support in the ILIAS Opencast plugin.

[LukasKalbertodt]

I just released octoka v1.0, meaning it is now ready to be used in production.

I also just opened this PR to support JWT auth in Opencasts /play route. This is by no means done yet, but should work fully for @ferishili to continue work on LMS stuff for now. This was a blocker in the past few weeks.