To put it simply, SSO (Single Sign On) means that in an environment where multiple systems coexist, after a user logs in in one place, he does not need to log in in other systems. trust. Single sign-on is frequently used in large-scale websites, such as Alibaba. There are hundreds of subsystems behind the website. One user operation or transaction may involve the cooperation of dozens of subsystems. If every All subsystems require user authentication, not only will the user go crazy, but each subsystem will also go crazy for this logic of repeated authentication and authorization. In the final analysis, the realization of single sign-on is to solve how to generate and store that trust, and how to verify the validity of this trust by other systems, so the main points are as follows:
- store trust
- verify trust
If a system achieves the effect mentioned at the beginning, it is considered single sign-on. There are different implementation methods of single sign-on. This article lists the implementation methods I have encountered in development.
Using Cookie as Credential Medium
The simplest single sign-on implementation is to use cookie as a medium to store user credentials.
After the user logs in to the parent application, the application returns an encrypted cookie. When the user accesses the child application, the cookie is carried to authorize the application to decrypt the cookie and verify it. If the verification passes, the current user is logged in.
It is not difficult to find that the above method stores trust in the client's cookie, which is easily questionable:
- Cookies are not secure
- Unable to implement free login across domains
For the first question, the security can be guaranteed by encrypting cookies, of course, this is on the premise that the source code is not disclosed. If the encryption algorithm of the cookie is leaked, the attacker can forge the identity of a specific user by forging the cookie, which is very dangerous.
For the second question, it is even more flawed.
Implemented through JSONP
For cross-domain issues, JSONP can be used.
After the user logs in in the parent application, the cookie that matches the session will be stored in the client. When the user needs to log in to the sub-application, the application is authorized to access the JSONP interface provided by the parent application, and the request includes the URL under the domain name of the parent application. Cookie, the parent application receives the request, verifies the user's login status, and returns encrypted information, and the child application verifies the user by parsing the returned encrypted information, and logs in the user if it passes the authentication.
Although this method can solve cross-domain problems, the security is actually similar to storing trust in cookies. Once the encryption algorithm is leaked, the attacker can create a fake parent application locally that implements the login interface, and bind the Host to direct the request initiated by the child application to the local fake parent application and respond.
Because the attacker can completely forge the response request according to the encryption algorithm, the sub-application can also pass the verification after receiving the response and log in a specific user.
The method of page redirection
The last method introduced is to communicate through the redirection between the parent application and the child application to realize the safe transmission of information.
The parent application provides a login interface in GET mode, and the user accesses this interface through a sub-application redirection connection. If the user has not logged in, a login page is returned, and the user enters the account password to log in. If the user has already logged in, an encrypted Token is generated and redirected to the verification Token interface provided by the sub-application. After decryption and verification, the sub-application logs in the current user.
Compared with the previous two methods, this method directly solves the security problems and cross-domain problems exposed by the above two methods, but it is not as convenient as the previous two methods.
Safety and convenience are inherently a pair of contradictions.
Use an independent login system
Generally speaking, large-scale applications will separate the authorization logic and user information related logic into one application, called the user center.
The user center does not handle business logic, but only handles user information management and authorization to third-party applications. When the third-party application needs to log in, it forwards the user's login request to the user center for processing, and the user returns the credentials after processing, and the third-party application verifies the credentials, and then logs in the user.