0

Objective

I have to create way to use the same users to connect to multiple application, and i am thinking about how to do it and how to share the data between the applications.

Details

Each application will have an REST API and an Angular Frontend.

For now i thought about doing a application that will handle the connexion and the common data of the user (name, email...). This application would create a jwt token.

On every other application i would have a table with only the id of the user and application related data.

Theses application api would do rest api call on the auth api to verify the token,and to get the data.

If the user want to update his data the call would be directly to the auth api.

Problem

With that logic i can think about some problems that i don't have any answer right now.

First, when i want to get the data of one user i don't see any problems, but if i want more users i'm not sure thats a good idea.

For example if i want to get the list of the users in a csv file + some data linked in the current application. I could do a api call for each user but that could be a lot of call. Or one call with a parameters with the list of ids, but i think it would be mess to relink the data to my list.

To do the api calls i found a package: doctrine-rest-driver but it was last updated in 2019

Question

Do you think my approach is the good one ? Is there an other way to share the data between the applications ?

Or is there a way to create something like a view inside the application database, but from another server and with the structure updated ?

Improve this question
3
  • "but i think it would be mess to relink the data to my list." Really? Matching up a relatively small number of entities by ID doesn't seem hard to me.
    – Philip Kendall
    Dec 10, 2021 at 11:45
  • I meant in term of performance, maybe i'm wrong but if it's not a small number of entities, like thousands of users, would it be ok ?
    – Gregory Boutte
    Dec 10, 2021 at 11:50
  • Thousands is a (very) small number of entities. As a rule of thumb, if you can do it in memory on one machine it's a small number of entities.
    – Philip Kendall
    Dec 10, 2021 at 13:20

1 Answer 1

Reset to default
3

You want Oauth and OIDC. Yes it's complicated to set up at first, but it pays off in the long run to have proper auth and identity management from the start, because replacing it after the fact is even harder. What you are describing is already at least 80% of an Oath set up anyway. You can use Identity server/active directory/ something else and that would be responsible for holding all the user information (individual apps would probably duplicate some of this for usability reasons). Then you have a single source of truth for which users have access to which systems, that you can easily query if you need to provide reports about users.

Another side benefit of Oauth is you could offload any responsibility for passwords to other companies by just allowing login with Facebook/Google/Twitter/Git hub/etc.

Improve this answer
2
  • Ok, i see. I'll look into OAuth and OIDC. I understand the goal behind the duplication of some data, but i am afraid that the application data can be outdated. How would you trigger the update of data ? What would be the strategy so that the data is updated when needed ?
    – Gregory Boutte
    Dec 10, 2021 at 14:20
  • 1
    More generally what the OP is looking for is a Federated Identity System. Not a duplicate, but see my answer to What is the purpose of identifier-first login screens? for links to more buzz words.
    – Greg Burghardt
    Dec 10, 2021 at 17:01

Your Answer

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

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