My partner and I are planning to develop several phoenix apps for various clients. Any app we build is going to need an authentication/authorization system.

I would like to solve the problem once and for all instead of re-implementing a similar but subtly different auth approach in each app we build.

I have found this open-source solution: GitHub - dwyl/auth: 🚪 🔐 UX-focussed Turnkey Authentication Solution for Web Apps/APIs (Documented, Tested & Maintained) · GitHub

This is my understanding of how it works:

1. The authorization/authentication is abstracted out of any app we build and isolated in this one single Phoenix auth app. This clears up mind-space in the app we are building for our client.

2. This Phoenix auth app has some nice and somewhat advanced features, such as role-based access control (i.e., users can be super-users, admins, normal users, read-only users, etc) and encryption to keep user info secure in case the auth app’s database is compromised. It also removes all user info from the main app’s database, which also provides more security in case of compromise of the main app’s database.

3. The auth app runs on a different domain from any app that we are concerned about providing authentication for.

4. The system works via OAuth. Suppose this auth app is deployed at TadasajonAuth.com – users will then set up TadasajonAuth accounts and any other Phoenix app that we build for clients will use a TadasajonAuth login system – i.e., user will log in with their TadasajonAuth account, similar to how they might currently log in to some site using their Facebook, Twitter, Google, or GitHub accounts.

5. Since clients that we build apps for will prefer to have a fully personalized auth system, rather than having their users log in with some third-party system called TadasajonAuth, we will use clever logic in the auth app to detect which URL the user is coming from and show appropriate logos, colors, information, etc.

   • In other words, from our clients perspective, their fancy new Phoenix app running at the-clients-domain.com has an auth system running at auth.the-clients-domain.com with DNS settings that point auth.the-clients-domain.com to TadasajonAuth.com and as far as the client or any of their users know, this is a fully operational auth system that is dedicated to the client’s app only.

   • The fact that the app is also providing OAuth for other apps is completely hidden from the client and is also really of no concern to the client – i.e., it makes no difference to the client (except insofar as a single auth app is easier for us to control as developers and is therefore more secure and robust).

6. The auth app can still allow users to log in with various third-party services, such as Twitter, Google, Facebook, GitHub, Whatever – the auth app will have OAuth hooks set up for a dozen such services and we will just turn on / turn off whatever services we want to use for any particular client app we are building.

   • So if client one would like Google login, then we just use our auth app, configure DNS so it runs at auth.client-one.com, and configure it so that users visiting auth.client-one.com see only a Google login option.

   • Then if client two wants Facebook login, we just use our auth app, configure DNS so it runs at auth.client-two.com, and configure it so that users visiting auth.client-two.com see only a Facebook login option.

   • So we basically have a proxy OAuth app…

7. We will also have basic username, email, password login in case a client just wants that and does not want any third-party login service.

Please tell me what is wrong with this proposed solution!