What's the right way to handle authentication of users across 2 web applications

Question

There are 2 independently functioning web applications. Web-app1: (Flutter+Django+Postgres). Web-app2: (Angular+Spring+Postgres). Each of the web-apps has its own user database and are functioning independently. It is now decided to integrate the 2 apps such that Web-app2(Spring) will no more have it's regular users in DB (except for Admin user). Users created in web-app1(Django) will have to login via Angular as client and Spring should authenticate the users and provide all the functionality of Web-app2(Angular+Spring) just like before.

I am thinking of 2 options...

A. Configure Spring such that it directly access the Web-app1's DB. Spring will maintain a login table at its end (Postgres).

B. Spring will request Django API to access Web-App1 user's password+username and create security context.

Both the applications are owned by single team

EDIT: Users created in web-app1(Flutter+Django) will use the app for some Feature A. The same set of users will use web-app2(Spring+Angular) via Angular client for some other Feature B

Answer 1

Definitely a tricky situation if you don't have some sort of federated user auth between the apps. I think your best option would be to setup an Oauth2 server to issue tokens that could be used for auth in both apps. This is extendable as apps are added, can have fine grained access controls, but incurs the overhead of the extra app and complexity of Oauth2. If you don't want that overhead, then option B would best suited as it prevents the tight coupling of the Spring app to the Django app's database. The Django app will essentially work like an authorization server then, but I could see some pitfalls with access controls if the two apps aren't using exactly the same roles, groups, or permissions.

Answer 2

Jacob is exactly right, and I'll take the liberty to try to explain why.

So, you have your App1 which does the user management along with some business features. Then you have App2, which depends on App1 only for the user management. Apart from being a mix of responsibilities in App1 (which is ugly in itself) you create an unnecessary dependency.

Let's continue on this trail: a year from now, your client needs App3. As it worked so well before, you also depend on App1 for user management. Fast forward into the future, you have Apps 2 to 6, which all depend on App1 for the user management.

Now, your client determines that the business features of App1 are not needed anymore. Basically, you'd like to switch it off, but you can't as you screwed it into your IT infrastructure so tightly, that you can never get rid of it.

Even worse: as you used your own protocol you also cannot replace it with a piece of standard software. (At least not without doing major changes to Apps 2-6.)

Therefore: get yourself a piece of specialized standard software (e.g. KeyCloak) and connect your Apps with a standard protocol (Oauth2 / OIDC). Every serious server should have a readymade module for such a connection today, so there is not much effort involved.

And try to think over the complete lifetime of a piece of software early (wich always includes the end-of-life), so that you avoid maeuvering into a dead end.