Skip to content

Using JWTs

Jump to bottom
K. Andrew Parker edited this page Sep 5, 2021 · 2 revisions

Initial Requests via JWT (problemJWT)

  • The problemJWT request parameter delivers a payload with the 'usual' key-value pairs that are normally sent as POST/query params.
  • The problemJWT must be encrypted with the same secret provided in render_app.conf (problemJWTsecret).
  • Any concurrent POST/query params will be overriden by the values provided by the JWT.

Subsequent Requests via JWT (sessionJWT)

  • the sessionJWT contains the initial problemJWT as part of its payload, ensuring consistent parameters for rendering.
  • the sessionJWT also retains the history of submitted responses, allowing for review of previous submissions and accurate attempt count.
  • the sessionJWT, when submitted on its own, allows a user to 'pick up where they left off' -- rendering the results of the previous submission.
  • the sessionJWT is encoded with an internal secret (sessionJWTsecret) that does not need to be 'known' to the CMS

Responses via JWT (answerJWT)

  • A problemJWT may provide a JWTanswerURL parameter (this parameter is discarded if provided outside of a JWT).
  • JWTanswerURL must be an absolute URL, and it specifies the address to which the answerJWT will be sent after the render has completed.
  • The delivery of the answerJWT happens in parallel to the 'rendered problem' response to the original requestor.
  • The answerJWT is encoded by a secret (sessionJWTsecret -- TODO: support 3rd secret) that is internal to the renderer, through it could be configured to be identical to the problemJWT secret.
  • The answerJWT contains both the problemJWT and sessionJWT in its payload -- TODO: the sessionJWT already contains the problemJWT, is this duplication necessary (session is potentially privately encoded)?
  • The answerJWT also contains the total score for the submitted response.

Role of JWTs in CMS Architecture

  • The purpose of the sessionJWT is to retain the history of a user's interactions (number of correct/incorrect attempts, problem status, contents of each answer field for 'stickiness', etc) with the individual problem specified by the problemJWT.
  • The answerJWT is sent to the JWTanswerURL (somewhere on the CMS backend), so that the CMS can update the user's recorded score and ensure that the student 'picks up where they left off'.
  • If the CMS is not playing man-in-the-middle (MITM), then the answerJWT securely delivers the problem status to the CMS in order to track the user's progress for the problem in question.
  • If the CMS is operating as MITM, then JWTs are not necessary as users will not be interacting directly with the renderer.

In summary, JWTs allow a CMS to authorize a user to securely interact with a library problem directly from the renderer. The answerJWT ensures that the CMS is securely updated with the status from each of the user's interactions with that problem (even though the CMS is not directly included in the user <-> renderer communication).

Clone this wiki locally