See figure understanding how JWT can be used for single sign-on

Single Sign-on is one of my favorite technical solutions, and he can improve the convenience of the use of the product, on the other hand, he separated the needs of each application of the login services, performance and workload are good. Since the last study of how JWT has been applied to session management, and the use of CAs as a popular single sign-on framework in previous projects, it has been figuring out how to use JWT with single sign-on together, as much as possible to integrate the benefits of both technologies into the project. This article describes the implementation of SSO that I think of from CAs.

Objective

In fact, CAS this program is very good, very powerful, its latest version has been integrated JWT, so if you do not want to develop a single sign-on service, you can fully consider the use of CAs. But I think that when we do the project, perhaps in the beginning do not need such a strong product, CAS provides a lot of login form, and we only need to apply one of them, and it is because of the framework is strong, so it will be more complex, easy to use easy, but encountered some special needs, For example, if we want to login in CAs, we need to have a better understanding of its principles and APIs. Comprehensive consideration, or to clarify the principle of CAs, their own to achieve a basic SSO service more assured.

The content of this article requires a basic understanding of JWT and SSO, and you can learn about the purpose of JWT from these two articles: 3 ways of Web session management JWT implements token-based session management, and the following information can be used to understand the contents of SSO:SSO_ Baidu Encyclopedia.

Program Introduction

This article mainly introduces the realization principle of JWT SSO by the way of time series diagram, the technical implementation is not yet, but when you understand the principle of this scheme, you will feel that the final implementation is not particularly complicated, you can use any platform language to implement it. The following sequence diagram simulates three services, CAS, system A, system B, which are deployed in cas.com,systema.com and Systemb.com;cas, which are used to manage SSO sessions, and system A and system B represent actual business systems. I've explained the implementation details of this SSO scheme from five scenarios. Let's look at the first one below.

Scenario One: The user initiates the first access to the business system, assuming that the first time he accesses the Some/page page of system A, the process that ultimately successfully accesses this page is:

In this process, I think the key point of understanding is:

1. It uses two cookies (JWT and SID) and three redirects to complete the creation of sessions and the delivery of the session;

1. JWT's Cookie is written in the systema.com domain, so each time the systema.com is redirected, the JWT cookie is brought in as long as it is available;

2. Sid's Cookie is written in the cas.com domain, so every time the redirect to cas.com, sid this cookie will be brought in as long as there is;

3. How do I know if the current user has created an SSO session while validating the JWT? Because the payload of JWT stores the session ID of the previously created SSO session, when the CAS get JWT, it is equivalent to get the session ID, and then use this session ID to determine if there is a corresponding session object can be.

Also note that: The session inside the CAS service is the object created by the server, so consider the session ID uniqueness and session sharing (if CAS is deployed with clustering). The uniqueness of session ID can be handled by the user name password plus random number and then using hash algorithm such as MD5 simple processing; session sharing can be done with memcached or Redis, a dedicated cache server that supports cluster deployment.

Because the service side session has the life cycle characteristics, the expiration needs to automatically destroy, so do not write the session management, lest cause other problems, to GitHub to find open source cache management middleware to deal with. When storing the session object, simply cache the session ID as the Key,session object itself as value. In addition to session ID, the session object can also store business data such as user information obtained after login, so as to facilitate the call of the business system, and return the conversation data from within session.

Scenario two: After the user logs in, continue to access other pages of system A, such as Some/page2, whose processing is:

From this step, it can be seen that even after logging in, each time with the CAs check the validity of the JWT and the validity of the session, in fact, the effectiveness of JWT can also be placed in the business system inside the processing, but the effectiveness of the session must go to the CAs to complete. When CAs gets the session ID in the JWT, it can go to the session cache server to verify that the session ID corresponding to the Session object exists, does not exist, it means that the conversation has been destroyed (exit).

Scenario three: After the user logs on to system A, and then accesses other systems such as System B's resources, such as System B's some/page, it can eventually access to System B's some/page process is:

The key to this process is that when the first redirect occurs, it brings the SID cookie back to the CAS server, so the CAS server can determine if the session has been established, and if it has already been established, skip the login page logic.

Scenario Four: The user continues to access other resources of system B, such as Some/page2 of system B:

The logic of this scenario is exactly the same as scenario two.

Scenario Five: Log out if it exits from System B, the final process is:

The most important thing is to clear the SID of the COOKIE,JWT cookie that may be created by the business system, so it is not possible to remove the cookie from those systems at the time of exiting, as long as SID is cleared, So even if the JWT cookie is passed on to the service of the business system at the next visit, it will eventually be redirected to the CAS login page for processing because the SID inside the JWT is invalid.

Program Summary

Two key prerequisites for the above scenario:

1. The whole session management is actually based on the service-side session, except that this session exists only in the CAS service;

2. CAs trusts the JWT of the business system because the JWT is issued by CAS, which in theory can be considered legal as long as the certification passes.

The JWT itself is non-counterfeit, tamper-proof, but does not represent an illegal user as a normal usage initiation request, so a few general security policies should be used in the actual project:

1. Using HTTPS

2. Use http-only cookies for SIDS and JWT

3. Manage keys

4. Guard against CSRF attacks.

In particular, the CSRF attack form, many are drilling code vulnerabilities occurred, so once the csrf loophole, and be exploited, then others can use the obtained JWT, impersonate the normal user access to all business systems, the consequences of this security problem is still very serious. With this in mind, in order to minimize the damage even in the event of a vulnerability, a system ID can be added to the JWT to add a validation that only the system identity within the JWT passed in is consistent with the service that initiated the JWT authentication request, allowing validation to pass. In this way, an illegal user who gets a JWT for a system cannot be used to access other business systems.

When the business system and CAS initiate attach/validate request, you can also do some processing on the CAS side, because this request, in an SSO process, a system should only be sent once, so long as the system has been issued a JWT, then the subsequent Attach/validate requests from the same system can be ignored.

Overall, the benefits of this programme are:

1. Fully distributed, cross-platform, CAS and business systems can be developed in different languages;

2. Business systems such as system A and system B, can be implemented without server status

3. If you do it yourself, you can easily integrate user registration services and third-party login services, such as logins, in CAs.

Its drawbacks are:

1. The first time you log in to a system, three redirects are required (but can be optimized to two times);

2. Subsequent requests after login require session validation with CAs, so the performance load of CAS is larger

3. Subsequent requests after landing, each with CAS interaction, will also increase the request response time, affecting the user experience.

Summary of this article

This paper introduces the principle of realizing SSO with JWT in theory, hoping it can help some friends to understand SSO better and how to implement it. This scenario refers to the implementation process from CAs, which you can use to learn about the single sign-on implementation of CAS:

Https://apereo.github.io/cas/4.1.x/protocol/CAS-Protocol.html

It's not a very different process from me, but from a clear point of view, I'm going to be more clear, so it might be more thorough to read it in comparison.

In addition, the plan is not necessarily comprehensive, so if you find the problem, but also ask you to help correct, thank you very much:)

See figure understanding how JWT can be used for single sign-on