Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Context

  1. Mobile needs a way to call some ecommerce payment APIs using JWT tokens.

  2. Mobile is trying to switch the mobile authentication flow from Bearer access tokens to JWTs to simplify the edx-platform authentication story. 

    • Note: This may require additional work, and may not need to be a blocker for the ecommerce work.

    • See OAuth2 and Mobile for some past discussion on this topic.

  3. Ownership: 

    • Arch-BOM squad owns Open edX authentication. 

    • Security Working Group has security expertise.

    • Mobile squad owns mobile experience, including authentication.

Current Proposal from Mobile Squad

  • Implement switch from Bearer to JWT tokens by making the following changes:

    1. Request the initial access token be returned using the JWT format rather than the Bearer format.

    2. Update the exchange of 1st party access token for new login session to accept JWT in addition to Bearer access token.

    3. Update the exchange of 3rd party access token for 1st party access token to accept JWT in addition to Bearer access token.

High-level Feedback

  • For all changes, we need to be careful about potential security risks.

  • When the mobile squad wishes to proceed on the Bearer to JWT, there are a number of additional changes that would be required. See later section with more specific feedback.

  • Reminder: please write ADRs (Architectural Decision Record) to capture the current context, any decisions being made, and their consequences.

Bearer to JWT Proposal Feedback

It is important to get this right such that we don’t introduce any additional security risks.

Token Expiration

One major difference between JWT and Bearer access tokens is that the JWT is non-revocable. There is no database lookup for the JWT access token and it is simply trusted if found to be valid. 

One consequence of this is that a JWT should have a short lifetime in order to limit security risks if the token is hijacked.

Currently, the JWT access token has a 10 hour lifetime, but it should have a maximum lifetime of 1 hour (matching the current lifetime of JWT cookie). Tim McCormack notes that JWTs should probably have a max of 15 minutes in all cases, rather than 1 hour, but that is a separate potential discussion.

Private ticket for this work: https://2u-internal.atlassian.net/browse/ARCHBOM-2099

Password Grant Check

For the currently proposed 1st-party token exchange for session login using JWTs, we would need an equivalent check for _is_grant_password to not expand permissiveness of the endpoint. 

This would require changes. Some options may include:

  1. Maybe we add the grant type into the JWT payload, or

    1. To keep down size, maybe this is added as-needed and the decoder can fill in the default.

  2. Maybe we could use the JWT token as the Bearer Token in the database so the grant type can continue to be accessible via the database lookup?

    1. See BearerToken docs as reference.

    2. Pros:

      1. This would continue to make the JWT revocable for this use case.

      2. The DOT access token wouldn’t be a string that is never actually used.

    3. Cons:

      1. I’m guessing all of our Bearer tokens would be in the JWT format, but use the “Bearer” header, which may get confusing.

      2. I’m not clear on all of the implications of a change like this.

Asymmetrically Signed JWT

In addition to the password grant check, we may need to check if the JWT was asymmetrically signed by the LMS.

If a JWT can be created (signed) by another IDA, then if that IDA is compromised, the attacker will be able to create JWTs that are accepted by all the other IDAs, including the LMS. If those JWTs can then be exchanged for session cookies, this would allow for full compromise of any user.

Asymmetric signing indicates that we're probably distributing the public (verification) key to the other IDAs and only exposing the private (signing) key to the LMS, which is very important if JWTs can be "escalated" to sessions.

It is unclear how this would be done. This information may be in the signature? Tim McCormack may have ideas.

Alternative Bearer to JWT Proposals

Alternative 1

For creating a session, in place of the token exchange endpoint, maybe it would be possible to create the session during the original access token request using an additional query parameter? Here we have access to the Password Grant information.

Note: I’m unclear about the 3rd-party to 1st-party token exchange, and if that would also require some of the above discussed validation, or if it would just work under this alternative proposed flow.

Alternative 2

Mobile can make an access token request for a JWT token with the refresh token and use it where it is required, and continue to use the existing Bearer token for initiating a session and the 3rd-party to 1st-party token exchange.

Notes:

  1. This would be a short-term fix that unblocks the ecommerce work, but doesn’t fully solve removing the Bearer tokens.

  2. We should still investigate if the JWT tokens should switch from 10 hours to 1 hour.

  • No labels