Solving auth once and for all -- does this proposed solution make sense?

Phoenix Forum Questions / Help
, , , ,
1

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)

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!

3 Likes
2

General note: “one auth to rule them all” can be a serious tarpit - especially if it spreads from pure authentication (“who is this user”) into authorization (“what can this user do”). Beware scope creep.

There’s potential cookie headaches with this approach - code on the “auth” site can read and set cookies in the toplevel domain the-clients-domain.com.

Re: per-client customization - you’ll also want to think about how things like password reset emails will work. Will clients want to supply custom branding images or language?

Specifically related to the repo above, the big thing that jumps out is a lack of multitenancy: a Person can be looked up by email alone, which means that the same email can’t be a user on client-one.com and client-two.com. :scream_cat:

3 Likes
3

Thanks for your feedback @al2o3cr

As far as scope creep, well, authorization is something that all my client apps are going to need, so that’s just baked in to the initial scope for me – I like the fact that this auth app from DWYL comes with authorization and roles built in – that’s a huge plus for me.

Also, since it is an open-source project, I’m planning to clone it and make some modifications to suit my use-case. I imagine that every time I build a new client app that will use this auth system, I’ll just add the name of the new client app to a table in the auth app – so the auth app will have internal awareness of which client apps it provides authentication for – and then I will allow lookup based on email+app, or some other custom logic.

As for your concern about cookies – well, both apps are controlled by me, so if the auth app is able to set cookies, I don’t see that as a security concern – I suppose it will allow me to track which people use two or more client apps that I have built, but I should be able to do this anyway, just by examining my database. Is there some further concern in regard to cookies?

1 Like
4

My worry is that you’ll like it a lot less when Client A and Client B make conflicting requests that impact the same role definitions. :frowning:

Couple thoughts on this:

  • that project already has a thing called “apps” but they aren’t the same; at a minimum, you’ll want to devise a new term for one or the other
  • multitenancy is not the sort of thing that you want to handwave with “well I assume we’ll do this somehow”; adding it to an existing application requires touching almost every function, and good luck merging in changes from upstream once you’re done.

If you control auth.example.com and the main site uses cookies set on example.com (regardless of if it’s run by you or not), your application can read and overwrite those cookies. Depending on your clients’ industry, that may be a compliance headache.