Authentication protocol

• Session Auth versus JWT Auth for Browser FE?
  • Decision: converging on a single Auth (OAuth+JWT) for mobile apps, browser apps, and external apps may result in a simpler implementation for API developers.
  • If JWT
    • Store JWT tokens in Session Cookies or in LocalStorage?
      • If Cookies: Backend middleware to retrieve JWT token from session cookie before Django Authentication middleware?
    • Security (To be answered)
      • What are security repercussions of Implicit Grant and how to protect against them?
        • For example, what should the Redirect URL be to protect against misuse of retrieving the OAuth Client ID from JS?
      • How do we revoke a token once it's been given out?
        • Example patterns: blacklists, versioned tokens, API gateway translation (opaque keys from client, API gateway translates into JWT to service)
    • Is it okay for clients to inspect the JWT payload for information, or should they treat JWTs as effectively opaque?
      • Consideration: Yes, clients can inspect in order to avoid additional calls to the backend for "simple" data such as username.  JWT tokens are versioned.

Decisions

• Frontend applications should use OAuth2 Authentication to access Backend APIs.
  • Mobile apps already do this.  New (fully split) FE applications would also do so.
• Each Micro-Frontend would have its own OAuth2 Client-ID to authenticate to the Authorization Server and to associate with its own requested Scopes.
  • For example, a Learner Support (admin portal) micro-frontend may have grades:write scope, but a Learner Content Consumption (learner portal) micro-frontend would have only grades:read.
• OAuth2 tokens should be stored and transported via Session Cookies, with appropriate security protections.

OAuth Scopes

• Should it include end-user permissions as well as the application's limitations?
  • If yes, how do we separate ownership between microservices and centralized auth service?
  • Consideration: No.  See API Authorization Notes.
  • Alternatively, see how Scopes can be used for Roles-based Access Control: https://wso2.com/library/articles/2015/12/article-role-based-access-control-for-apis-exposed-via-wso2-api-manager-using-oauth-2.0-scopes/.
• How are scopes defined/managed? Feature-based or service-based?

Auth Service

Options

1. Status quo; keep Auth service embedded within LMS.  Just fix all other IDAs.
2. Externalize Auth service from LMS; move out all auth-related code from the LMS into a separate library.
   1. Initially it can run in its own service, while sharing the database with the LMS.
   2. Eventually it can migrate its data from the LMS to the new service.
3. Use a new Open Source library, like KeyCloak that handles all auth-related features.  Focus on migration of LMS and other IDAs.
4. Use an external SaaS platform, like Auth0, with integration points for Open edX to plugin their own.