Unsolved questions

• [ ] How will the testing change so that each recipe can be tested independently?
• [ ] Is it possible to easily create a recipe by mixing and matching from other existing recipe, without having to maintain another recipe (this problem may quickly lead to an explosion of recipes which will become very hard to maintain)? For example:
  • [ ] if there is a remember me functionality is email, password recipe, and I want to add that in Mobile OTP recipe, how can I do that easily?
  • [ ] If there is a brute force prevention method in email and password, how can I add that to username and password?
  • [ ] I'm afraid that this architecture might lead to the case where to build a recipe that meets the demand for only one app might take so much effort, that it's not worth it for them.
• [ ] How would independent parts of the overall auth system interact with each other? Based on the below, it seems that there will be two types of recipe - login & session, which will have a defined interface they must conform to so that they both can talk to each other and also provide SSO. What would that interface be?
  • [ ] How would different session recipes fit in with login recipe? For example, some session recipes might want to show the login page after a certain amount of time (without logging out the user - think github, when clicked on manage access).
  • [x] For something like sending verification emails, there are many providers that can be integrated with. But those integrations should not be recipe specific.. In the sense, any recipe can take advantage of those integrations. So where should such integrations fit in? Similar argument goes for integrating with analytics - both email/password and mobileOTP recipes should somehow all work with a set of analytics integrations that already exist.
    • [x] We can put all of this in the core, and expose their functions via the api-interface so that the recipe modules can use them as needed.
    • [x] On the frontend and backend, have callbacks for analytics.
  • [ ] For SSO, how would different login & session recipe communicate to do single login & logout?
• [ ] How can we make switching between recipe as seamless and non breaking as possible?
• [ ] How would we propagate a super recipe ID if it is using an existing recipe?

Recipe

• This is one instance of a full auth solution. For example, login with email & password, which will contain login, sign up & password reset.
• Each recipe has a global unique ID.
• One can build a recipe on top of another one. In this case, the recipe ID of the existing recipe will change to their unique ID. This is so that if someone is using the super recipe and the sub recipe together, there are no clashes.
• Combining two recipes will result in a third, separate recipe.
• A recipe consists of three modules: frontend, driver and core.
• How each module communicates is dictated by that recipe's FDI & CDI. For both, a header value is added (rId) that dictates which recipe this call is made from. We are not doing a query param since a session recipe doesn't have the luxury of it's own API.

Module

• Frontend module
  • This contains everything that the recipe needs to work on the frontend.
  • It is built up of many features. For example, an email & password recipe will have:
    • sign up
    • login
    • reset password
  • Each feature can have several themes that dictate that features's UI and UX.
  • This module will automatically provide certain full page UI / UX so that the user has some features out of the box. They can be disabled.
• Driver module
  • This contains everything that the recipe needs on the the API layer.
  • This module will be made up of several features that will help the user with various operations that this recipe provides. Each feature would have a set of functions associated with them. For example, an email & password recipe will have:
    • signUp(email, password)
    • login(email, password)
    • getResetPasswordCode(email)
    • resetPassword(code, newPassword)
    • emailExists(email)
  • This module will also provide various pre written APIs that automagically use these functions to provide the required functionality. They can be disabled.