Summary
Unify our login efforts by using a standardized format like Google OAuth to handle logins to the platform for security and ease of access.
Problem
We have an awesome, robust authentication server that was built out by Product Infrastructure, which is currently in use. It's a great tool for being able to quickly integrate auth into our applications. However, as we move towards increased complexity with multiple chapters & organizations using the platform, there are two main issues that can complicate things as we begin to expand this:
Auth has to be deployed on its own as a microservice. This is great if we had clear coordination of microservices and could easily maintain both the API server and the auth server. However since we want teams to be able to rapidly launch this platform in their own environments, less abstraction here is better, and it leads to less maintenance in the long run. Same for dev—it let's us iterate quicker by just launching one unified backend instead of multiple working pieces.
We don't need the robustness that having a full username/password authentication system provides. In fact, this can be somewhat more challenging to maintain as users need to remember another set of credentials, and there are more points of failure & edge cases that can be difficult to solve if someone is not already familiar with the inner workings of our internal auth server.
Solution
PassportJS has a great OAuth strategy which can be integrated to our application with few lines of code (I estimate under 50). I think it's an awesome, lightweight solution for projects that use authentication, especially with it handling a lot under the hood while also providing a lot of customizability.
However, the rather few lines of code written are challenging (conceptually) to understand. I hope that the LAH OAuth integration can serve as a reference point for this. In addition, there are some great online explanations that help to guide the setup and intuition behind some of the more conceptually challenging serializeUser and deserializeUser.
Acceptance Criteria
[ ] As a superadmin, I should be able to specify which users are directors.
[ ] As a director, I should be able to specify which emails are able to access the platform in the UI.
[ ] As a director, I should be able to dynamically modify which users are able to access the platform.
[ ] As a platform user, I should be able to click a button on the log-in page to log in with OAuth, and no other options for logging in.
[ ] As a platform user, if I am not on the list of users who have access, I will be directed to an unauthorized page.
[ ] As a platform user, I only see pages in navigation (and can only access) those which are available to me in my role.
Summary Unify our login efforts by using a standardized format like Google OAuth to handle logins to the platform for security and ease of access.
Problem We have an awesome, robust authentication server that was built out by Product Infrastructure, which is currently in use. It's a great tool for being able to quickly integrate auth into our applications. However, as we move towards increased complexity with multiple chapters & organizations using the platform, there are two main issues that can complicate things as we begin to expand this:
Auth has to be deployed on its own as a microservice. This is great if we had clear coordination of microservices and could easily maintain both the API server and the auth server. However since we want teams to be able to rapidly launch this platform in their own environments, less abstraction here is better, and it leads to less maintenance in the long run. Same for dev—it let's us iterate quicker by just launching one unified backend instead of multiple working pieces.
We don't need the robustness that having a full username/password authentication system provides. In fact, this can be somewhat more challenging to maintain as users need to remember another set of credentials, and there are more points of failure & edge cases that can be difficult to solve if someone is not already familiar with the inner workings of our internal auth server.
Solution
PassportJS has a great OAuth strategy which can be integrated to our application with few lines of code (I estimate under 50). I think it's an awesome, lightweight solution for projects that use authentication, especially with it handling a lot under the hood while also providing a lot of customizability.
However, the rather few lines of code written are challenging (conceptually) to understand. I hope that the LAH OAuth integration can serve as a reference point for this. In addition, there are some great online explanations that help to guide the setup and intuition behind some of the more conceptually challenging
serializeUseranddeserializeUser.Acceptance Criteria