On the user Information data Management of Unified Authentication Service

I didn"t want to register repeatedly, but wanted to integrate into a microservice, so I began to search, think, and design, but I encountered a key problem as I walked:

where should I put my user data?

the reason for this confusion is to consider the following things:

1.:...

2....

3.

4.

I"m not asking how to unify authentication. I want to know more about the architecture design of services, especially when designing data structures.
for example: how are Ali"s services (Taobao, Tmall, Alipay.) designed for their user data structure?

as far as the results are concerned, there should be only two orientations: user information management is either managed on the side of the unified authentication service, or distributed to each application system for its own management.

Mar.21,2022

  1. Why does the unified authentication service care about what the user type is? this is something that callers need to consider
  2. user information only stores key information that is used for unique distinction, such as ID card and mobile number used by Ali Taobao, login account number and password belong to account attributes
  3. callers only need to know whether this person exists or not, confirm that it exists, and then query it in their business table through the uid issued by the center
  4. Let's first encounter a bottleneck. If you can rely on machine hardware to heap, use hardware heap

take a chestnut:

  1. users register with any business party, and the business direction center asks (mobile phone number, ID number, usually identity ID ) whether they have registered an account

    1. Tell the user to change the identity ID or directly log in with the identity ID binding account or continue to register with the identity ID (this depends on the business)

    2 has not been registered. Go through the registration process. The center registers identity ID and bound account attributes (account name, password, etc.), and then issues a central user id (hereinafter referred to as cuid )

    .
  2. register the information fields required by the business in the business side, associate cuid with these information fields to form a user of the business side (hereinafter referred to as buser ), and then submit some public fields such as name and gender to the center, so that the next time you register another business account with the same identity ID , you can directly distribute some information (which smacks of privacy abuse. Therefore, business permission and technical identity verification are required, that is, send a verification code to the mobile phone number / transfer 1 cent to the bound bank card to confirm that it is indeed the same natural person registering)
  3. users log in to any business party, and the business asks the center whether the account name and password exist in the match. After the verification is passed by the center, cuid is pushed. The business side gets cuid to see if it has any buser associated with it. Without telling the user to register, log in and start the business process with buser .
Menu