Single sign-on (SSO) simply means that in an environment where multiple systems coexist, a user does not need to log in to other systems after logging in to one system. That is, a user’s Single login can be trusted by all other systems.
Single sign-on (sso), very frequently used in large sites like alibaba web site, for example, the site is behind hundreds of thousands of subsystem, the user an operation or transaction may involve dozens of subsystems of collaboration, if every subsystem needs user authentication, users will not only crazy, each subsystem is repeated certification authorization logic to get crazy.
Implementing single sign-on is all about how to generate and store that trust, and how to verify the validity of that trust by other systems, so the key points are as follows:
Storage of trust
Verify the trust
SSO can be said as long as the above problems are solved and the effect described at the beginning is achieved. The easiest way to implement SSO is to use cookies, as follows:
Otherwise, it is found that the above scheme is to store trust in the Cookie of the client. Although this method is convenient to implement, two questions will immediately be questioned:
Cookies are not safe
No cross-domain free boarding
In fact, the idea of this solution is to store the trust relationship in the client. To achieve this, it is not necessary to use cookies, but flash can also solve the problem. Flash’s Shared Object API provides storage capabilities.
In general, large systems store trust relationships on the server as follows:
The above solution stores the trust relationship in a separate SSO system (let’s call it that), which is a simple move from the client side to the server side, but there are several issues that need to be addressed:
How to store large amounts of temporary trust data efficiently
How to prevent the information transfer process from being tampered with
How do I get the SSO system to trust the login system and the no-login system
For the first problem, you can generally use a distributed caching solution similar to memcached, which provides both a scalable data volume mechanism and efficient access. For the second problem, digital signature is generally adopted, either through digital certificate signature or md5, which requires SSO system to encrypt the parameters to be verified with MD5 encryption and return them with token. Finally, when the system to verify the trust relationship is required, This token is passed to the SSO system, which verifies the token to determine whether the information has been changed. The last problem can be addressed by whitelisting. Simply put, only systems on the whitelist can request the production trust relationship. Similarly, only systems on the whitelist can be exempted from login.