Authentication protocol

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.

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?

Status quo; keep Auth service embedded within LMS. Just fix all other IDAs.
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.
Use a new Open Source library, like KeyCloak that handles all auth-related features. Focus on migration of LMS and other IDAs.
Use an external SaaS platform, like Auth0, with integration points for Open edX to plugin their own.