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

2 Answers 2


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.

  • Thanks for the quick response. The goal is web-app1 will be responsible for user creation and user will use web-app1 for some Feature A. The same set of user will use web-app2 for a different Feature B. Both apps will continue to serve different purpose. I was more inclined to use option A
    – mAsK
    May 14, 2021 at 5:07
  • Makes sense. Option A is the most straight forward approach as it lets web-app2 access the auth data directly. The trade off there is the tight coupling caused by a shared database, which may be fine in your situation. In my experiences, a shared database has caused more trouble than it's saved. May 14, 2021 at 5:24

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.

  • Thanks for the excellent explanation. I thought of this thread today while I was debugging issues caused by using a shared database at enterprise scale. Proof that proper upfront engineering is invaluable. Good question, @mAsk! May 15, 2021 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.