In a web system, user login is the most basic feature. To achieve username + password login, many students’ first ideas are to create a UserS table directly, contain two columns of username and password so that they can be logged in:
ID | Username | Password | Name, etc. Other fields —- +——– +——– + ————- — A1 | BOB | A1B23F2C | … A2 | ADAM | C0932F32 | …
Now the problem is coming, if you want to log in to a third party, such as Weibo login or QQ login, how to integrate?
Taking Weibo as an example, because Weibo uses OAuth2 protocol to log in, a login user will include the ID of his Weibo identity, an access token to represent the user to access Weibo API and an expiration time.
To integrate microblogging, many children’s shoes immediately think of extending the UserS table to several columns, record microblogging information:
ID | username | password | weibo_id | weibo_access_token | weibo_expires | Name, etc. Other fields —- +——– +—— + ——- – + ——————– +———— + ——— ——- A1 | BOB | A1B23F2C | W-012345 | XXXXXXXXXX | 604800 | … A2 | ADAM | C0932F32 | W-234567 | XXXXXXXXXX | 604800 |
Add a QQ login USERS table, you need to add 3 columns. If you expand it, you have to die, don’t say to maintain the code.
How can you design a flexible login?
Take you consider the user login at an angle. When the user logs in any way, we read the line record corresponding to the user table, which is actually a profile, and the login process is just to authenticate the user (Authenticate), no matter Locally password verification, or entrust a third party login, this process is essentially certified.
So, if you separate the Profile and Authenticate, it is easy to understand. The UserS table is only stored by the user’s Profile:
ID | NAME | Birth, etc. —- +—- +————— A1 | BOB | … A2 | ADAM |. .
The username visual login can be considered an Authenticate, using the LocaLauth table maintenance:
ID | user_id | username | password —- +——- + ———- + ———– 01 | A1 | BOB | A1B23F2C 02 | A2 | ADAM | C0932F32
Sign in to Weibo can be regarded as another Authenticate method, using OAuth table maintenance:
ID | user_id | weibo_id | weibo_access_token | weibo_expires —- +——- + ———- + ————— —– + ————— 11 | A1 | W-012345 | XXXXXXXXXX | 604800 12 | A2 | W-234567 | XXXXXXXXXX | 604800
If you want to add another OAuth login, such as QQ login, add a table. However, since everyone is the OAuth family, it is better to unify it to a table, and it is good to give each name:
ID | user_id | OAUTH_NAME | OAUTH_ID | OAUTH_ACCESS_TOKEN | OAUTH_EXPIRES —- + ——– + ———- + ———- +——————– + ————— 11 | A1 | Weibo | W-012345 | XXXXXXXXXX | 604800 12| A2 | weibo | W-234567 | XXXXXXXXXX | 604800 13 | A1 | QQ | Q-090807 | XXX-XXX-XXX | 86400 14 | A2 | QQ | Q-807060 | XXX-XXX-XXX | 86400 If you want to add oneNew login mode, such as SAML, then add a type of table.
Each X-Auth table stores the user’s login authentication information and is associated with the user_id.In this way, not only is the login process simplifies, but a user can use a variety of ways to log in.As long as the login is successful, I get the user_id, and finally read the UserS table is to obtain the user’s profile, so the read data is safer, because the user does not include the user password, not because exposed the API, accidentally put the password to leak the password.