The session mechanism for login: HTTP is a stateless protocol, and every request a browser makes is independent of the others. But not every HTTP request is unrelated to state, so the browser and the server have to jointly maintain a state β this is the session mechanism. One approach: the first time the browser sends a request to the server, the server returns a sessionID to the browser, and every subsequent request from the browser carries that sessionID to verify the same user. Another approach: the server issues a token for user authentication and app authorization. This article mainly introduces two common login methods: third-party login and single sign-on (SSO).
1. Third-Party Login
A user (one party) uses an existing account (a third party) to quickly complete login and registration for another network service (the other party) β this is called third-party login. The service that provides the ID is called the IdP (Identifier Provider). The service that provides other services is called the SP (Service Provider).
1.1 Pros and Cons
Pros:
- Reduces the cost of user registration
- Maintains existing user relationships
- Lowers development and maintenance costs
Cons:
Not conducive to conveying marketing information; you cannot obtain information such as the user’s phone number or email address.
1.2 Use Cases
Suitable for applications that provide tools or content.
1.3 Implementation Options
OAuth2.0
2. Single Sign-On
A user only needs to log in once to access all mutually trusted application systems. It includes a mechanism that maps this primary login to logins for the same user in other applications, and it is currently one of the more popular solutions for enterprise business integration.
2.1 Pros and Cons
Pros:
- A unified user information center
- Reduces the login development work for subsystems
Cons:
- Hard to refactor
- Security risks. Once an account is logged in, it can freely log in to other sites.
- Easy to be chosen as a target of attack.
2.2 Use Cases
Suitable for large enterprises with multiple sites, especially those with complex and diverse internal systems.
2.3 Implementation Options
Shared Cookie:
When the subsystems are all under one parent domain, plant the Cookie under the parent domain and obtain the SessionID through the Cookie. There are restrictions on the subsystem domains. This approach can actually be seen as sharing the session.
Token verification:
When a subsystem needs to log in, it redirects to the SSO page for login, a token is issued, and the subsystem uses the token to call the SSO to obtain user information.
